[Robert, read the end of this message]

John,

I forgot to take the list of project members (left the pad in my office --
am on West Coast now, in fact off the coast on an Island). 

Here is the part for 5 & 6.  Will you pass it to your colleagues (perhaps
cc me then i have their emails too). 

I will also send you the project 4 description which is the DB substrate
for your work. 

There is a lot of extra excitement since we will also want to integrate
your server into a UBIK server which Robert Watson and some other people
are building. 

- Peter -

Yale Protection Server for Coda
-------------------------------

We want an RPC2 client/server system which can modify the protection
database, described for project 4.  We are going to model this on the
AFS command pts.  You will first want to read Satya's paper:
"integrating security in a large distributed environment" to learn
about Coda permissions, authentication and authorization. Bradley has this
paper. 

pts allows the creation of groups, adding users to groups etc. Here is
the command summary from "pts help" and a help page:

pts: Commands are:
adduser         add a user to a group
apropos         search by help text
chown           change ownership of a group
creategroup     create a new group
createuser      create a new user
delete          delete a user or group from database
examine         examine an entry
help            get help on commands
listmax         list max id
listowned       list groups owned by an entry or zero id gets orphaned groups
membership      list membership of a user or group
removeuser      remove a user from a group
rename          rename user or group
setfields       set fields for an entry
setmax          set max id

Creating and Using AFS Group Rights

You may have a large group of people to whom you want to give special rights
in a directory: a class you teach, for example. With the "pts" ("protection
server") command, you can create a group name and add people to it. You can
then add the group to the directory access list as you would any individual
user and change directory access rights for a large number of people in a
single operation.

Using groups to grant access rights is also useful as a directory tree
grows: A new AFS directory automatically inherits its parent's access list.
If you find after creating a string of subdirectories that there are some
things you would prefer some group member not see, you can remove his/her
name from the group, thus removing that member's access at all levels in
only one step. This procedure is preferable to the tedious process of
removing an individual name from each subdirectory access list.

This file tells you how to:

   * create a group
   * understand and use the privacy flags
   * use pts commands

Creating a group

   * Choose a group name in the format

     user:identifier.identifier

     For example, bovik:my.colleagues
   * Type

     pts creategroup group

   * To add users to a group, use

     pts adduser user groupname

% pts creategroup bovik:my.class
group bovik:myclass has id -904
% pts adduser max bovik:my.class [Add members to the group]
% pts examine bovik:my.class    [Find out more about group]
Name:bovik:my.class, id:-808, owner:bovik, creator: bovik,
membership: 1, flags: S-M--, group quota: 19.
% fs sa manual bovik:my.class rlidwk
% fs la manual
Access list for manual is
Normal rights:
bovik:my.class rlidwk
system:friendlyhost rl
system:authuser rl
bovik rlidwka

Understanding and using the privacy flags

In the output to the "pts examine" command shown above, note the portion
labeled "flags: S-M--". This series of letters and dashes are called
"privacy flags." They indicate who has permission to make changes to the
group. Usually the default group setting shown here is sufficient. If for
some reason you want to allow group members to make additions and deletions
to the group, you can do so using the "pts setfields" command. Type "pts
help setfields" for the command syntax. The flags have the following
meanings:

   * Status (s): List status information about an entry via "pts examine"
   * Owned (o): List groups a group or user owns via "pts listowned"
   * Membership (m): List groups a user belongs to, or users that belong to
     a group via "pts membership"
   * Add (a): Add a user to a group via "pts adduser"
   * Remove (r): Remove a user from a group via "pts removeuser"

Grant these rights to different classes of users in these ways:

   * To system administrators and the entry owner only: type a hyphen
   * To group members only: type the letter in lower case
   * To the world: type letter in upper case

Thus, the default flags "S-M--" indicate that everyone may use "pts examine"
and "pts membership" on an entry, but only system administrators and the
entry owner may list the groups owned or add and remove other users.

Other useful commands

pts examine userid
     See if user exists, and if so, some information about him/her.
pts examine groupname
     Find more information about the group.
pts members userid
     Find out which groups user belongs to.
pts members group
     Find out which users are in the group.
pts removeuser -user userid -group group
     Remove a user from the group.
pts delete group
     Delete a group.

For a list of possible options, type

pts help

or see the online manual page here if you're using a machine running Mach;
otherwise, type "man pts."

The model for your server is something like the "au" server talking to
the protection database server auth2. 

A) set up a skeleton client/server which given unauthenticated access to the database (we will build in authentication later on):

Example RPC2 servers are in the RPC2 source code, or you can look at
au/auth2, in coda-src/auth2.  Make sure you first try to run stest and
ctest in rpc2 to get a feel for what's going on.

Do your work in the Coda sources.  Make a new subdirectory
coda-src/pdbnet (the pdbstuff stuff will go away).  Make a Makefile.in
in coda-src/pdbnet based on the one in coda-src/fail or auth2, edit
the toplevel configure.in to make sure it creates your new Makefile,
run autoconf and finally ./configure in the build area to set up your
Makefile (perhaps it is handy to make the Makefile by hand first and
postpone the Makefile.in stuff until later).

You must compile through coda-src/rpc2 and probably not beyond libal
before your directory gets compiled. (edit Makefile.in in coda-src) to
control this.

  a)  model the client program as follows:
      ypc command args
      should execute a function "command" which takes as arguemnts:
      argc-1 (from main) and a char ** equal to &argv[1], i.e. it
      takes all the arguments of yps shifted right.

      This is very important since it will allow you to change the
      program into a nice interactive program using the parser library we
      built.  Look at coda-src/fail/filcon if you are curious.

  b)  the Yale protection server yps should return some data (use a
      text buffer), and return an error code if an error occured.

  
  c)  hook this up to the functions provided by project 4. (see the
      project 4 description which I will also mail to you). Then you
      have a working yps! (which we would just __love__ to have!!!).


The authentication to this server is of course important, but I am not
100% clear yet how you are going to tackle this -- I will get back to
you about this. (see below)

Keep me posted!!! Good luck. 

- Peter  -


Robert: I think it would be safe to ask Venus to deliver the encrypted
and unencrypted session key to pts _provided_ the pts (ypc)  process is
in the PAG for the session keys.  Probably yps should have the option of
taking a parameter which is a user for which the keys should be used. 

This would be better than kerberizing ypc independently since it would
work always even on the non-encrypted version of Coda.