Provided by: netplan_1.10.1-6_amd64 bug


       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 the
       /var/lib/plan/netplan.dir directory, 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 version 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 numbers of messages.

       -a     Authentication  via  IDENTD  (RFC 1413) is mandatory.  If authentication 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  the  /var/lib/plan/netplan.dir  directory.
       netplan  will  not access any files that are not in this directory or in subdirectories of
       this directory. It will also refuse to access  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  rejected  to
       prevent access to netplan-acl and other future configuration files.

       /etc/plan/  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 current user, containing that user's ``own''

       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  address.  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 symbolic 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

       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 access 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, respectively.

       netplan tries to verify the identity of  the  client  user  with  the  IDENTD  (RFC  1413)
       protocol.   If  the identification succeeds, the client username 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 identification 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 different.


       netplan  trusts  IP  addresses  to  determine  host  (network) access restrictions.  If IP
       addresses cannot be trusted, host access restrictions become 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 more.)

       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 protection.

       The  location  for  /etc/plan/netplan-acl is specific to Debian GNU/Linux.  For compliance
       with    FSSTND/FHS,    it    has    been    moved    there    from     its     traditional
       /var/lib/plan/netplan.dir/.netplan-acl location.  The program still accesses that file via
       a symlink located at the traditional location.


       Thomas Driemeyer <>

       Please send all complaints, comments, bug fixes, and porting  experiences  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 with the line "subscribe plan" (without the
       quotes) in the message body (not the subject).

       See for new releases.