PLAN(1L)

NAME
netplan - IP server for plan(1) appointment lists

SYNOPSIS
netplan [-f] [-d] [-v]

DESCRIPTION
netplan is an IP server that serves calendar data to plan(1) programs. It maintains a directory, by default /usr/local/lib/netplan.dir, 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.

  OPTIONS

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

FILES

All files accessible to netplan are stored in a directory netplan.dir which resides in the directory LIB as set in the Makefile, /usr/local/lib by default. 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.

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. The syntax for .netplan-acl file is a sequence of rules like this:
    name | * : [permit | deny] [read] [write] [netmask n.n.n.n]
               [[user | group | host] data [data ...]]
name is the file the rule applies to; an asterisk (*) applies to all files. 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, it is derived from that address according to the usual rules if missing. data is one or more numerical UIDs, numerical GIDs, or numerical n.n.n.n IP addresses for user, group, and host rules, respectively. User is the default. 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
    vacation: permit write user 207
    thomas: deny
    thomas: permit read write user 207 208
    announce: permit write netmask 255.255.255.0 host 10.0.1.0
first permits reading all files to everybody. The second line permits write access to the file vacation to user 207, in addition to the read access permitted in line 1. 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 had to be specified explicitly because IP addresses that begin with a number less than 128 specify class-A networks whose default netmask is 255.0.0.0. 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 ID, and IP address. The final setting of these flags determine the permissions of the file for the client. Note that although the syntax was roughly patterned after TIS fwtk firewall configuration files, the code and interpretation is rather different.

SECURITY

In short, there is none. All access lists should be regarded as advisory. 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. 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 guard against accidental read or write access to data, but not more.

  AUTHOR
Thomas Driemeyer <thomas@bitrot.in-berlin.de>

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 plan-request@bitrot.in-berlin.de.

See http://www.in-berlin.de/User/bitrot for new releases.