NETPLAN(8)NETPLAN(8)NAMEnetplan - IP server for plan(1) appointment lists
SYNOPSISnetplan [-f] [-d] [-v] [-a]
DESCRIPTIONnetplan 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
(Debian 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.
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 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
below.
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 or /usr/freeware/lib (SGI) or /usr/lib/plan (Debian
Linux) 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 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
address. The default netmask is 255.255.255.255. 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 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 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‐
tively.
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
different.
SECURITYnetplan trusts IP addresses to determine host (network) access restric‐
tions. 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 protec‐
tion.
SEE ALSO
plan(1).
AUTHOR
Thomas Driemeyer <thomas@bitrot.de>
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‐
domo@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.
NETPLAN(8)
