NETPLAN(8) NETPLAN(8) NNAAMMEE netplan - IP server for plan(1) appointment lists SSYYNNOOPPSSIISS nneettppllaann [-f] [-d] [-v] [-a] DDEESSCCRRIIPPTTIIOONN nneettppllaann is an IP server that serves calendar data to ppllaann(1) programs. It maintains a directory, by default /usr/local/lib/netplan.dir or /usr/freeware/lib/net­ plan.dir (SGI) or /usr/lib/plan/netplan.dir (Debian Linux), that contains calendar files and an access list file. ppllaann users can name files and hosts in their file list dialog, which causes ppllaann to establish a connection to nneettppllaann on the given host and request data from the file. nneettppllaann 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 ppllaann programs of changes so they can update their displays. OOPPTTIIOONNSS -f Runs in the foreground. This is useful for debug­ ging. -d Debug mode. This implies -f. All connections and transactions are logged to the terminal. Among other things, the program version and file loca­ tions 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 ppllaann or ppllaanndd ) support the identd authentication service (you can find out by running ``telnet clienthost 113''; if telnet reports ``Con­ nected'' type Ctrl-D, clienthost support identd). If a client host that does not support identd con­ nects to a nneettppllaann 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 below. FFIILLEESS All files accessible to nneettppllaann are stored in a directory netplan.dir which resides in the directory LIB as set in 1 NETPLAN(8) NETPLAN(8) the Makefile, /usr/local/lib or /usr/freeware/lib (SGI) or /usr/lib/plan (Debian Linux) by default. nneettppllaann will not access any files that are not in this directory or in sub­ directories 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 nneettppllaann .. Finally, files beginning with a dot are rejected to prevent access to .netplan-acl and other future configuration files. netplan.dir may also contain a file .netplan-acl that con­ trols which user can access which file. If the file is missing, no restrictions are imposed unless nneettppllaann 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...]] _n_a_m_e is the file the rule applies to; an asterisk (*) applies to all files. The special name _o_w_n_e_r applies to the file by the name of current 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 _n_e_t_m_a_s_k applies to the client's IP address. The default netmask is 255.255.255.255. _d_a_t_a is one or more user names or numer­ ical 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 proto­ col always uses numerical IDs and assumes that they corre­ spond to the same symbolic names on both hosts. If no user, group, or host keyword and _d_a_t_a list is specified, the meaning is ``any''. Trailing n=0 IP address components are not assumed to denote nets; use the _n_e_t_m_a_s_k specifier for subnet masking. All whitespace is ignored. Pound signs (#) introduce comments that extend to the end of the line. For example, 2 NETPLAN(8) NETPLAN(8) *: 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 255.255.255.0 host 10.0.1.0 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 _v_a_c_a_t_i_o_n to user 207, in addition to the read access permitted in lines 1-2. Next, read and write access for file _t_h_o_m_a_s is granted to users 207 and 208 only. Finally, the file _a_n_n_o_u_n_c_e can be written by all users on hosts whose net­ work 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 ppllaann client as given by his user ID, group IDs, and IP address. The final set­ tings 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. nneettppllaann tries to verify the identity of the client user with the IDENTD (RFC 1413) protocol. If the identifica­ tion 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, nneettppllaann trusts the (numerical) identity provided by the client. If the -a option is given on the invocation of nneettppllaann,, 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. SSEECCUURRIITTYY nneettppllaann 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 nneettppllaann is 3 NETPLAN(8) NETPLAN(8) used through the regular ppllaann 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 ppllaann (the sources are, after all, freely available) to circumvent the access restrictions. If RFC 1413 authentication is mandatory (-a flag), nneettppllaann 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 nneettppllaann, no challenge-response encryp­ tion 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. SSEEEE AALLSSOO ppllaann(1). AAUUTTHHOORR Thomas Driemeyer Please send all complaints, comments, bug fixes, and port­ ing 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 majordomo@bitrot.de with the line "subscribe plan" (without the quotes) in the message body (not the subject). See http://www.bitrot.de/plan.html for new releases. 4