afs pts schema?

[Lyle Seaman]

Marcus Watts wrote:

 > Something I guess I've never

> understood, though, is just how does the CM do permissions checking
> when a second person tries to access a file the CM already has in
> its cache acquired under someone else's credentials.  It looks
> like the CM does a RXAFS_FetchStatus everytime - so I suppose
> that must be how this works.

Essentially, yes.
RXAFS_FetchStatus returns a bitmask of access rights: rwildka
It returns those access rights for the calling user, and also for system:anyuser.
When the CM tries to access a cached file on behalf of a second user, if the
existing system:anyuser rights are not sufficient, then it does another
RXAFS_FetchStatus call and remembers those
bits as well, for some time.  This is in afs_axscache.c and the routines that call
into it.


> The CM *does* know about acl's, however, to the extent that it
> implement the pioctl's VIOCGETAL and VIOCSETAL, and it also
> does at least read vice ID's in files to return the owner.

The "owners" as listed by ls -al, for example, are generated by looking for
the viceid in /etc/passwd (or NIS or whatever).  IOW, there's an implicit assumption
that
viceids and uids are always the same.  That has nothing to do with the ptserver.
Sucks, though, the nsswitch and the filesystem really should use the same mappings
--
a strong point in favor of using LDAP.

(wouldn't it be nice if when you ran "ls -l" on files in somebody else's cell, you
saw meaningful names, instead of seeing the nonsense created when /bin/ls uses your
/etc/passwd to resolve somebody elses ownership data?)

The CM really doesn't know about acls, actually.  The VIOCGETAL and VIOCSETAL are
just silly little hooks to spare the "fs" command from having to include RX (which
is moot, now).  They RXAFS_GetACL RPC does not return ACLs in the "native" on-disk
format, complete with viceids, but rather, the fileserver makes repeated id2name
calls to make up a more-or-less human readable ACL, and then returns it.
 Conversely, the SetACL RPC takes a long text string, digs out the names, and calls
name2id on them.  These are two of the slowest RPCs and biggest performance hogs in
the fileserver, fortunately, they aren't used often.  The only thing that knows
about ACLs is the fileserver, and the fs command (and the afs/dfs translator).

> I believe it will be real painful to get rid of the underlying
> assumption that there's a mapping between vice IDs, loginids, and
> pt names, and moderately painful to replace ACLs with something else.

Don't give up too easily -- I think it sounds harder than it is, if you can
find the right approach...  IMO, replacing the ACLs would be much harder
than sorting out the mapping between ids and names, and I can't really see
why you'd want to.

> Assuming you keep AFS acls and vice IDs, then the problem
> that remains is to map from a kerberos name, to a list of
> vice IDs.  That's basically what pr_GetCPS does.  You'd also
> need to map from a kerberos name to the one vice ID for
> that name, which is pr_NameToId.  If you can duplicate
> those two bits of codes, you can replace ptserver, but you
> could probably just as easily put that code in a sort of stub
> driver to emulate ptserver, and not muck with the fileserver code.
> (well, 2.5 places -- there's also pr_GetHostCPS, and one
> errant call to pr_IdToName for logging purposes.)
>
> If you did decide to muck with the fileserver code, you'd want to make
> sure your replacement for GetCPS, ACLs and/or NameToId allowed other
> threads to proceed if your thread has to block resolving file
> permissions or user identity (say, waiting for a response from a remote
> network server.)  It's harder to do that with tcp (ldap) than with rx
> (pts) but still possible.

I believe that all of the above is true.

One thing to keep in mind is that the ptserver  installation and management is
really quite easy and consistent with the rest of AFS, whereas  most of the likely
replacements are not.  It would be sad to see the ptserver replaced by some
overambitious rube goldberg affair, just because the buzzword value is greater.