NETFS(8) NETFS(8)
NAME
netfs - network file system
SYNOPSIS
/usr/netb/setup.go
DESCRIPTION
The network file system is conventionally a set of directo-
ries contained in and a set of files and programs in Connec-
tions in the network file system are asymmetric: files on a
`server' system are made accessible on a `client' system,
usually in directory /n/server-name.
Client
The client runs to maintain connections; it is started by
invoking from rc(8). Setup uses to control the connections
to servers. Each line in friends contains six fields:
network address
network call argument
mount point
protocol id
unique identifier
debugging flag
network calling username
The network address and argument give the location of the
server. They are interpreted differently according to the
protocol id, which should be one of
d Call the server on the named network address, with
default network `dk' and default service name `fsb'.
The network call argument is ignored. The server
machine should respond by calling zarf, described
below; see svcmgr(8).
t Call the named network address, with default network
`tcp', and invoke the program named in the network call
argument using the protocol of rsh; con(1).
Setup calls setlogname (see getuid(2)) to make the network
call appear to have been placed by the calling username.
The username may be omitted; `daemon' is the default.
The mount point is the directory on which the remote file
system is to appear. The unique identifier is a integer in
the range 0-255; it is used internally to distinguish con-
nections, and must be unique among all active remote file
systems (including those not maintained by setup, e.g.
faced(9.5)). The debugging flag is usually 0; nonzero num-
bers increase the chatter in various logfiles.
NETFS(8) NETFS(8)
Setup reads the friends file when it starts, and checks for
changes once a minute. Each remote file system is probed
once a minute; if there is no response to several consecu-
tive probes, the connection is torn down and restarted.
Failed connections are retried every minute.
Server
The server program is A separate zarf process exists for
each client.
When a connection is started, the client sends the server a
list of valid user and group names and the corresponding
numerical IDs on the client system. The userid and groupid
of user and group names that exist on both machines are
mapped so that client and server see IDs under the same
names. Unmapped IDs on the server appear as -1 on the
client. Client processes with unmapped IDs are denied
access.
Zarf is subject to access control on the server. It will
have access only to files that its own userid and groupid
admit. Unless run as super-user, it will create files with
its own, not mapped, userid.
Zarf reads configuration information from and The files are
read only once, when zarf starts, except.local first. Usu-
ally except is the same on all machines in some administra-
tive cluster, except.local contains things specific to a
particular server system.
The files contain sections beginning with the line client
origin. Origin is the name of the calling client, as pro-
vided by the network; `*' matches any client. The first
matching section is used.
Within each section, lines have of one of the following
forms. Lines beginning with `#' are ignored.
uid cname=sname
Regardless of the contents of password files, map
client user name cname to server user name sname. If
cname is not announced as valid by the client, the line
is ignored. If sname is not a valid name on the
server, any previous mapping for cname is discarded.
gid cname=sname
Map client group name cname to server group name sname,
as above.
param otherok=val
If val is `1', client processes with unmapped userids
are granted world access to existing files on the
NETFS(8) NETFS(8)
server. Unmapped userids may never create files (who
would own them?). If val is anything else, no access
is permitted to unmapped client userids.
param root=pathname
Use pathname rather than / as the root of the filename
hierarchy made visible on the client.
EXAMPLES
A friends file for a connection to alice over Datakit,
shamash over TCP/IP, and bebop over TCP/IP without adminis-
trative help:
alice - /n/alice d 0 0
tcp!shamash!400 - /n/sun d 1 0
bebop /usr/pjw/netb/zarf /n/bebop t 2 0 pjw
Some except file rules:
client dk!nj/astro/research
param otherok=1
client *
uid root=
gid mail=other
param otherok=0
param root=/usr/spool
If the research machine calls as a client, the whole file
system tree is visible, all userids including the super-user
are permitted normal access, and user names unknown to the
server are permitted world access. If any other machine
calls, only the contents of /usr/spool are visible, root and
unknown users are explicitly denied access, and processes in
group mail on the client are treated as if in group other on
the server.
FILES
out of date.