[92] in DCNS Development
revised proposal for "permit" command
daemon@ATHENA.MIT.EDU (Mark Rosenstein)
Wed Aug 14 17:22:44 1991
Date: Wed, 14 Aug 91 17:19:45 -0400
From: Mark Rosenstein <mar@MIT.EDU>
To: developers@MIT.EDU, release-73@MIT.EDU, athena-ws@MIT.EDU
I would like to get more feedback on this now that I've reviewed and
incorporated comments from the original proposal. The next step will
be a sample implementation to further understand the complexity of the
problem and test the proposal. This would be followed by a formal
design review, and then a real implementation. With any luck, it will
all work sometime this fall.
-Mark
The "permit" command can solve a number of problems in the NFS->AFS
migration:
* users shouldn't need to know AFS is different
* fs is not friendly enough
* chmod/chgrp/chown need to work recursively with ACLS
* make_readable needs to work with AFS
Permit would be able to:
* change file/directory permissions
* change file/directory ownership
* change AFS acls
* display accessibility
* work recursively
* remember what it does for later undo
The program may be invoked via two names: permit or deny. Deny does
the opposite of permit, removing access and permissions.
The basic syntax is "permit|deny [options] [who] command file(s)".
where who is "world | group[:groupname] | user[:username]"
and command is "read | execute | write | show | owner | undo | help"
and options are "recursive | quiet"
Who this operation applies to may be "world", "group[:groupname]", or
"user[:username]". World means everybody. In AFS this is
"system:anyuser". Group takes an optional groupname. If not
specified when setting file ownership or AFS permissions, it will
default to the name of the user executing the command. If not
specified when changing NFS permissions it will keep the same group
ownership as the file already has. User also takes an optional
username, with the same defaulting as the group name except for
setting AFS permissions where it will actually use the owner of the
file rather than the person executing the command.
The command may be "read", "execute", "write", "show", "owner",
"undo", or "help". Read, execute, and write will set the permissions
of the file. They may have to change the permissions of directories
above the target file to achieve this. A warning will be displayed if
the requested change affects files other than the one(s) specified
(i.e. making a file world-readable in AFS makes all files in that
directory readable). The "show" command will describe who owns and
has access to the specified file(s). The "owner" command will set the
ownership. The "undo" command will reverse any perviously taken
actions with respect to the named file(s). Undo gets its information
from the checkpoint file /tmp/permit${UID}.ckp, which permit
automatically appends to each time it modifies the filesystem. Help
will print out some helpful text.
There are several options that will modify the commands. "Recursive"
or "under" will apply the permission or ownership change recursively
to all files in a tree starting with the specified directories.
"Quiet" will suppress warnings.
The following syntax is available on the unix command line. Syntax:
prog [option] [who] command [option] files
permit recursive world read under
deny quiet group [groupname] execute
user [username] write
show
owner
undo
help
All keywords may be abbreviated to a single letter (note that the
abbreviation for undo is a capital U):
permit|deny [r|q] [w|g[:group]|u[:user]] r|e|w|s|o|U|h [u] files
AMBIGUITIES: Given the flexibility of the syntax, some commands are
ambiguous. The flags to permit have been carefully chosen so that
they may be parsed unambiguously. But what if the file you want to
work with has the same name as an option, i.e. "permit world read
under" where under is the file, not the option? In an attempt to
handle the most common case, the program will assume that the option
is being specified (conflicts should be rare). If you really want it
to be the file, put "./" on the front of the filename.
Examples:
permit world read ~
makes the user's home directory world readable
permit world read under ~
makes the user's home directory and everything under it world
readable
permit group:16.001 write ps-1 ps-2 ps-3
makes the three files ps-1, ps-2, and ps-3 each writable by
the members of group 16.001. This may require a chgrp & chmod
in NFS or adding an acl in AFS. If doing this also changes
the accessibility of other files, permit will print warnings
about this.
deny world execute vaxbin/*
makes sure that the whole world cannot execute the programs in
vaxbin.
permit recursive world read /mit/foo/src
permit world read under /mit/foo/src
there are equivalent. they make the directory /mit/foo/src
and everything under it world readable.
permit user:mar owner foo.bar
Changes the ownership of file foo.bar to user mar.
permit recursive group:sysdev owner /source
Changes the group ownership of /source and everything
underneath it to sysdev.
permit show ~
displays the accessiblity of the user's home directory
permit r u:carla r /mit/project; du /mit/project; permit U /mit/project
makes /mit/project and everything under it readable by carla,
measures the disk space in the locker; and then restores the
permissions to what they were before
permit undo /mit/project
undoes everything done by the previous command while affected
/mit/project.
