Hi Matthew,

Good to hear from you.

On Sat, 18 Apr 1998, Matthew Hiller wrote:

> 	Hello. We have a few questions to ask with regards to our work on
> the PAG project: 
> 
> Clarifications of one of your e-mails:
> 
> >4. To make sure that Coda exploits PAGs modify the void
> >coda_load_creds(struct coda_cred *cred) routine in coda_linux.c and stuff
> >the current->pag contents into current->egid (for now). 
> 
> 	At present, coda_load_creds stuffs current->egid into
> cred->cr_egid. Do you mean that we should stuff current->pag into
> current->egid, and then stuff that into cred->cr_egid, or do you mean
> something else?

The best thing (if you are up to it) is to add a field to the struct
coda_cred struct for the pag.  It's defined in coda.h
(kernel-src/vfs/includes).  Recently I needed the euid for something in
venus, so I'd prefer not to lose that.  Otherwise use the suid field. 



> 
> > 5. Then you need to look how this is used in Venus but we will discuss
> > that later on. 
> 
> 	We're ready to start looking at this - let us know how to change
> the way Venus makes use of the PAG information it will be passed.
> 

First of all it extremely important that you first get yourself a working
venus; if it doesn't work beforehand without pags, you are not going to
get far with pags.

I have forgotten if you depend on the Yale setup, or if you run at home. 
In the home case after installing the stuff there is a user admin with
password changeme defined (uid 500).  You should add some users (see hte
Coda manual on the WWW and/or ask Henry Pierce hmpierce_at_cs.cmu.edu to help
you).

Now make some directories with different ACL's.  Use the cfs setacl
command. DON't change the top directory /coda for fooling around, since
you might lock yourself out.  Use a tree under /coda/tmp or so. 

The vfs calls from the kernel module, containing your pag come into Venus
in the file vproc_vfscalls.  The macro CRTOUID should be replaced.  I
suggest passing a pointer to the coda_cred structure from the kernel, that
gives the Access function (see below) the best chance at doing a good job.
If you define that macro to be the identity, the type of access changes,
and it is passed a struct coda_cred * as the last parameter.

The calls determining access are the methods 
fsobj::Acces (fso_cfscalls2.cc).  The crucial lines in the Access call
are:
	userent *ue;
	GetUser(&ue, vuid);
	int tokensvalid = ue->TokensValid();
	PutUser(&ue);
	vuid_t CheckVuid = (tokensvalid ? vuid : ALL_UIDS);

	if ((code = CheckAcRights(CheckVuid, rights, 1)) != ENOENT)
	    return(code);

Getuser is also passed the coda_cred and should find the uid for which you
have given the pag (see below). The routine doing this is Finduser in
user.cc.  It should first go through the list matching the pag and then
try other options (see below).  For this to work the userent must be given
a "pag" field. (user.h).

At this point in time Venus would authenticate a user with pags, but we
haven't yet installed  the pags.  For this we go to clog.  Clog gets a
session key from the authentication server in exchange for the correct
password.  Currently the clog program then gives venus the (uid, sessions
key).  I should add the pag to that.  The crucial call to give Venus
something is a pioctl call. There we go:

In coda-src/login/clog.cc you see U_SetLocalTokens.  This is defined in
coda-src/auth2/avenus.c and you even see a commented out setpag call
there (ignore it).  You have hopefully writtent a system call that gives a
process its pag, let's call that getpag. Now right above that call you see
the structure venusbuff.  Make the first field a new pag field and stuff
the pag in that.  Rename this struct to struct LocalTokenBuf.

The pioctl call goes to the coda kernel module and hands the buffer
straight to Venus. This ends up in venus in vproc_pioctl.cc, in the case
VIOCSETTOK.  You see some pretty horrible coding here: we should have n
include file in the auth2 directory defining LocalTokenBuf which
vproc_pioctl.cc and avenus.cc both include. If you don't want to do that
(adding files is messy with the Makefiles) then just redefine that
structure in vproc_pioctl.cc and I'll pick it up. 

In the handling of the pioctl, you see another GetUser call.  Here the
user should be found by uid -- in other words you want a call GetUser
described above, matching pags and one of the form GetUserById for
authentication, to be used here.  Finally you modify SetTokens and you are
done.  Almost that is, since I have some other things up my sleeve.  See
below.



> A question about system calls:
> 
> 	Presently, we cannot make use of any system calls that we have
> defined ourselves without explicitly using _syscalln() macros that are
> either directly in our user programs or in include files for them. I'd
> assume there's a more elegant way of doing that - what is it?
> 

Write a small library calling the macros.  Eventually things like this may
find itself into the C library but that will be a long time from now.
Which system calls do you have.

> A question about concurrency:
> 
> 	If two processes call newpag() at the same time (which causes a
> global or static variable maxpag to be incremented), could this possibly
> cause a race condition? (It seems to us that it does.) If so, are there
> semaphores built into Linux we can use to avoid the race conditions (or
> would you recommend that we use some other method)?

I recommend just using the global kernel lock; finally we are talking
about a few machine instructions. 

BTW there is a chance that we can get this code into the 2.1 mainline
kernel, but I think we need to hurry.  Would you mind giving me all the
kernel stuff you have, then I can start negotiating with Linus (of course
I will give you credit for all the work. It might be advantageous if I try
to get it in since a lot of issues came up on the lists when I floated the
idea, and someone needs to fight that off). 

Now the extras.  They are the following:

1) a flag "--unsafe" should be passable to clog and enable old style
authentication.  This means that GetUser first tries to match the pag and
then checks "unsafe" user entries and matches them by uid.  This also
needs to be passed by clog to Venus in the buffer. (default is pag).

2) a flags --exec should be passable to clog which does the following.  It
authenticates the user with the auth2 server.  Then it does newpag BEFORE
installing the new pag and tokens with Venus, finally it execs the
remaining arguments.  The result is a new process with a new pag which is
authenticated.  This prevents all other processes in the current pag from
becomeing authenticated and getting too much power.  For example:
clog --exec bash gives a new authenticated shell; all other shells remain
unaffected.

3) root should be allowed to authenticate (currently it is blocked
somewhere).  2) is especially important for root, since careless
authentication by root might authenticate daemons running in the same pag.  

I'm thrilled you have the syscalls that's great.  If you find this too
much work, just give us the syscalls we'll do the rest, and you will get a
good grade. 

Peter


> 
> Thanks very much,
> Matt Hiller
>