Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
NETPLAN(8)		    System Manager's Manual		    NETPLAN(8)

       netplan - IP server for plan(1) appointment lists

       netplan [-f] [-d] [-v] [-a]

       netplan	is an IP server	that serves calendar data to plan(1) programs.
       It maintains a  directory,  by  default	/usr/local/lib/netplan.dir  or
       /usr/freeware/lib/netplan.dir  (SGI)  or	/usr/lib/plan/netplan.dir (De-
       bian Linux), that contains calendar files  and  an  access  list	 file.
       plan  users  can	 name files and	hosts in their file list dialog, which
       causes plan to establish	a connection to	netplan	on the given host  and
       request	data  from  the	file.  netplan handles multiple	connections to
       the same	file, sequences	updates	to files such that no data can be lost
       if  multiple simultaneous updates are requested,	and notifies connected
       plan programs of	changes	so they	can update their displays.

       -f     Runs in the foreground. This is useful for debugging.

       -d     Debug mode. This implies -f. All	connections  and  transactions
	      are logged to the	terminal. Among	other things, the program ver-
	      sion and file locations are printed.

       -v     Verbose. Together	with -d, the verbosity of the log messages  is
	      increased	to include data	requests. this can generate large num-
	      bers of messages.

       -a     Authentication via IDENTD	(RFC 1413) is mandatory.  If authenti-
	      cation fails, map	the client to UID/GID NOBODY. Use this only if
	      all connecting client hosts (running plan	or pland ) support the
	      identd  authentication  service  (you  can  find	out by running
	      ``telnet clienthost 113''; if telnet reports ``Connected''  type
	      Ctrl-D,  clienthost  support identd). If a client	host that does
	      not support identd connects to a netplan server run with -a,  it
	      will have	no or restricted access. Also, if you use -a, you must
	      have a .netplan-acl file or no access is granted to anybody; see

       All  files  accessible to netplan are stored in a directory netplan.dir
       which resides in	the directory LIB as set  in  the  Makefile,  /usr/lo-
       cal/lib	or  /usr/freeware/lib (SGI) or /usr/lib/plan (Debian Linux) by
       default.	 netplan will not access any files that	are not	in this	direc-
       tory or in subdirectories of this directory. It will also refuse	to ac-
       cess softlinks and files	with multiple hard links. This prevents	 users
       from  linking  normally inaccessible files to netplan.dir and accessing
       them through netplan .  Finally,	files beginning	with  a	 dot  are  re-
       jected to prevent access	to .netplan-acl	and other future configuration

       netplan.dir may also contain a file .netplan-acl	 that  controls	 which
       user can	access which file. If the file is missing, no restrictions are
       imposed unless netplan is started with the -a option, in	which case  no
       access  to  any	file is	granted. The syntax for	.netplan-acl file is a
       sequence	of rules like this:

	   name	| owner	| * : [permit |	deny] [read] [write] [delete]
			      [netmask n.n.n.n]
			      [[user | group | host] data [data...]]

       name is the file	the rule applies to; an	asterisk (*)  applies  to  all
       files.	The special name owner applies to the file by the name of cur-
       rent user, containing that user's ``own'' appointments.

       Permit is the default. If none of read, write, or delete	are specified,
       all  three  are the default. The	netmask	applies	to the client's	IP ad-
       dress. The default netmask is  data  is	 one  or  more
       user  names  or	numerical UIDs,	group names or numerical GIDs, or host
       names or	numerical n.n.n.n IP  addresses	 for  user,  group,  and  host
       clauses,	 respectively.	In  user clauses, values of the	form user@host
       are also	accepted. Symbolic names will be looked	up on the server  host
       (where  netplan	is  running) and will be converted to numerical	values
       while the ACL file is read. This	assumes	that all hosts agree  on  sym-
       bolic  and numeric user,	group, and host	IDs; the plan/netplan protocol
       always uses numerical IDs and assumes that they correspond to the  same
       symbolic	 names	on  both hosts.	If no user, group, or host keyword and
       data list is specified, the meaning is ``any''.

       Trailing	n=0 IP address components are not assumed to denote nets;  use
       the netmask specifier for subnet	masking. All whitespace	is ignored.

       Pound signs (#) introduce comments that extend to the end of the	line.

       For example,

	   *: permit read
	   *: permit write host	daphne
	   vacation: permit write user 207
	   thomas: deny	user *
	   thomas: permit read write delete user 207 208
	   announce: permit write netmask	host

       first  permits  reading all files to everybody, and restricts write ac-
       cess to users on	host daphne. The third line permits  write  access  to
       the file	vacation to user 207, in addition to the read access permitted
       in lines	1-2.  Next, read and write access for file thomas  is  granted
       to users	207 and	208 only. Finally, the file announce can be written by
       all users on hosts whose	network	address	begins with  10.0.1.  Trailing
       ".0"  parts  need not be	entered. The netmask basically specifies which
       bits of the client address are compared;	all addresses are binary-ANDed
       with the	netmask	before comparison.

       When  opening  a	 file,	the  rules are scanned sequentially. All rules
       whose file part (before the colon) matches  the	opened	file,  set  or
       clear  permission  flags	for reading and	writing, based on the identity
       of the plan client as given by his user ID, group IDs, and IP  address.
       The final settings of these flags determine the permissions of the file
       for the client.	The final permission setting is	the AND	result of  the
       permissions  derived for	the host/netmask, and user/group part, respec-

       netplan tries to	verify the identity of the client user with the	IDENTD
       (RFC  1413) protocol.  If the identification succeeds, the client user-
       name is mapped to UID and GIDs per the local passwd and group files  on
       the  server  host.  If RFC 1413 identification is unsuccessful, netplan
       trusts the (numerical) identity provided	by the client.

       If the -a option	is given on the	invocation of netplan, RFC 1413	 iden-
       tification  becomes mandatory, and a failed identification will map the
       client to the NOBODY UID	and GID.

       Note that although the ACL syntax was roughly patterned after TIS  fwtk
       firewall	 configuration	files,	the  code and interpretation is	rather

       netplan trusts IP addresses to determine	host (network) access restric-
       tions.  If IP addresses cannot be trusted, host access restrictions be-
       come meaningless.

       Without RFC 1413	authetication, netplan trusts  whatever	 user  id  and
       group  id the client provides.	If netplan is used through the regular
       plan front-end application, the access  list  file  specifications  are
       honored,	 but  any  half-witted	programmer can fake his	identity using
       telnet or a hacked version of plan (the sources are, after all,	freely
       available) to circumvent	the access restrictions.

       If RFC 1413 authentication is mandatory (-a flag), netplan still	trusts
       whatever	the remote identd provides.  If	you cannot trust root  on  the
       remote  host,  you  cannot trust	the identd result.  (And if you	cannot
       trust IP	addresses, you effectively cannot trust	the  remote  root  any

       In this version of netplan, no challenge-response encryption is used to
       guarantee secure	transactions.  This may	or may not  change  in	future
       versions. In this version, access lists provide only a moderate protec-


       Thomas Driemeyer	<>

       Please send all complaints, comments, bug fixes,	 and  porting  experi-
       ences  to me. Always include your plan version as reported by "plan -v"
       in your mail.  To be added to the mailing list,	send  mail  to	major-  with  the line "subscribe plan" (without	the quotes) in
       the message body	(not the subject).

       See for new releases.



Want to link to this manual page? Use this URL:

home | help