[OpenAFS] Hardware Grants from Sun

Jeffrey Hutzelman jhutz@cmu.edu
Sat, 24 Feb 2007 13:13:25 -0500 (EST)

On Sat, 24 Feb 2007, Nicolas Williams wrote:

> I'm not sure how important it is to have per-session network
> credentials, but I do sympathize -- if nothing else it's what AFS users
> are accustomed to.  Issues surrounding how per-user network credentials
> are handled are a separate, but related concern.

If nothing else, it makes them easier to manage when a user has multiple
overlapping sessions on the same machine.  There are also plenty of people
for whom it's really important to be able to maintain multiple sets of
network credentials in one session, often simultaneously.  I use that
capability nearly every day to do things like install software without
giving the bits required to do so to my email client or web browser.  I'm
sure Jeff Altman can make plenty of arguments in this area.

> > >As for home directories; we've been putting users' home
> > >directories in AFS for O(15) years, though we only appear to have been
> > >supporting Solaris since 1995. If you have specific issues, please
> > >describe them instead of asking that Sun be "willing to state a desire"
> > >for things to work that already do.
> >
> > There are still issues with having to have an AFS token before any
> > files in the home directory are accessed, even the .k5login. Since this
> > is a general OS problem.
> >
> > The point is things don't work as well as they could, partly because the
> > OS developers don't use AFS. This "acceptance of a "gift" might be the
> > time to get Sun to look a little closer at how things really work.
> I have no idea what gift you're talking about.  If Sun is donating
> equipment to the OpenAFS community, I think that'd be great.

So would we, but that's pretty much where it stands.  This thread started
with a proposal to apply for a grant, along with someone's guess as to
what we might be able to get.  The latter was not intended to be made
public, and I think it has confused some people into thinking the process
is rather further along than it is.

> BTW, a PAG facility that's faithful to the AFS notion of PAGs should be
> relatively easy to specify and implement for Solaris, but it will be
> more involved than you might have thought.  That's because we have
> proc(4), proc(1), truss(1) and ucred_get(3C) to worry about, plus
> libproc.  So we're talking about:

>  - new getpag()/setpag() syscalls and library stubs
>  - new cr*() functions
>  - procfs (proc(4)) exts (say, PCSPAG operation to set a proc's PAG)
>     - and libproc exts (Ppag(), Psetpag())
>     - and proc(1) exts (say, a new option for pcred(1), or a new cmd?)
>  - ucred_get(3C) exts (ucred_getpag(3C))
>  - kinit(1) exts?
>  - pam_unix_cred(5) exts? (set the caller's PAG!)
>  - extensions to krb5_cc_default() and gssd(1M) to find per-session
>    ccaches instead of per-user ccaches
> The ARC will have to see a spec too.  It'd help to have OpenAFS folks
> helping us get a spec together and get through the ARC review.

OK; but that's a discussion for security-discuss and openafs-devel (gee,
that will be fun for the moderators); it's sort of off-topic for

-- Jeff