(Illustration by Gaich Muramatsu)
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 >Received on 1998-04-19 12:43:49