[Fwd: Re: [OpenAFS-devel] Helpful OpenSolaris feature on the way...]

[Douglas E. Engert]

I had sent a note to Nico on this subject of CPGs and AFS PAGs
but I cc'ed the wrong mailing list. The following was his response.

Note the last few lines:

     The open inception is tomorrow at 10:25AM PDT.  You're welcome to dial
     in, listen in and participate:

     http://opensolaris.org/os/community/arc/announcements/

-------- Original Message --------
Subject: Re: [OpenAFS-devel] Helpful OpenSolaris feature on the way...
Date: Tue, 5 May 2009 14:33:31 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Douglas E. Engert <deengert@anl.gov>
CC: OpenSC-devel <opensc-devel@lists.opensc-project.org>,        Dale Ghent <daleg@elemental.org>, "Garrett D'Amore" <gdamore@sun.com>
References: <B133993C-1DA9-4F0C-A5F4-CA86E1FF5402@elemental.org> <4A00865C.90806@anl.gov>

On Tue, May 05, 2009 at 01:33:00PM -0500, Douglas E. Engert wrote:
> I saw this posted on the OpenAFS list. It looks very interesting.
> It looks like it tries to combine the best parts of session based ticket
> caches (which I have been requesting for years) with the needs of NFSv4,
> as well as AFS!

Indeed.

> But it sounds like the ticket cache is still stored in a local file
> system, which still uses the UIDs for access control. So sessions may
> not be as independent as one might like. Is there any way to impose
> access to the ticket cache based on the CPGs? Possibly using ACLs
> based on the CPGs? Temporary UIDs assigned to a CPG?

First, CCAPI is coming, though in a separate case, so you can make sure
that the CCAPI daemons do authorization based on whatever you want.

Second, for NFSv4 there's gssd, which will be per-user or per-session,
and again, we can make it do authorization however we like.
Enhancements to gssd will be a separate case too.

> IMHO Unix's Achilles heal has been the non-unique UID/GID used local
> file systems.

I'd say that the fact that POSIX IDs are in practice small, local-only
(NFSv3 and NIS and RFC2307+ notwithstanding) and unstructured (because
too small) is the problem.

ZFS nowadays stores SIDs, with POSIX IDs being, effectively, a variant
of SIDs (I'm simplifying, slightly).  So Solaris is already moving past
the POSIX ID limitations.

> I like to think the UID (or rather the UID in the cred_t) as being the
> credential used for access to the local file system. In the long run,
> there needs to be a local file system that uses other credentials
> other the the UID for access.

Session IDs are too temporary for use in persistent filesystems, though
fine for use in tmpfs.  Right now Solaris does not have a way to use
session SIDs for authorization to filesystem objects, but one could do
that in tmpfs (though first tmpfs will need several enhancements, like
support for SIDs).  Compatibility with stat(2) and friends could be done
by mapping session IDs to ephemeral UIDs/GIDs like we do with SIDs now,
but obviously getpwuid(3C) and getgrgid(3C) on those would fail, or
perhaps not return much of use.  I don't think we'll actually need this
though, as SIDs should suffice for our purposes.

Incidentally, our ID mapping solution can be extended to support
cross-Unix domain ID mapping, using SIDs as an internal go-between.
See: http://blogs.sun.com/nico/entry/can_we_map_ids_between

> With CPGs it looks like one could have a Unix system without UIDs!

Well, no, not really.  Files still need an owner and ACL entries need a
subject.  Again, we could treat CPG IDs as something like session SIDs
and then make sure that tmpfs supports those, but because session IDs
are necessarily ephemeral you could not have filesystems on disk (or
SSDs) reference them.

> Sounds a little like Windows? Use the PAC in a ticket for credentials?

For local filesystems I don't see the point.  We already have support
for SIDs, if that (something better than POSIX IDs) is what you're
looking for.  For remote filesystems the idea is to use whatever GSS-API
(and/or SASL/whatever) mechanism credentials the process is associated
with -- in fact, we do that _now_ in the case of the NFSv4 client, but
the association is by effective UID, which is just too coarse.

> >Just an FYI - Nicholas Williams (who I think may occasionally read this 
> >list) and Garrett D'Amore at Sun have proposed a dedicated area within 
> >Solaris's cred_t called Credentials Process Groups. In the context of 
> >OpenAFS, it could mean a dedicated area for storing PAG bits.

It's exactly what it is.  Basically each cred_t could have one or more
"CPGs", though only one of each registered "CPG type", and each CPG has:
a) a 64-bit unique (since boot) ID, b) room for "user data", c) hooks
for kernel-land consumers (e.g., filesystems) to hang arbitrary data and
cleanup callbacks on any CPG.  Each CPG type has a name and a set of
semantics flags.

I believe you're after (a) (which should do as a PAG ID for AFS) and
(c).

In fact, CPGs are really PAGs + multiplicity + kernel API + "user data".

> >This ARC case is still pending, mind you.

The open inception is tomorrow at 10:25AM PDT.  You're welcome to dial
in, listen in and participate:

http://opensolaris.org/os/community/arc/announcements/

I may well need help substantiating the claim that associating
cryptographic authentication mechanism credentials with process
effective UID is too coarse.  Though I think the audio uses of CPGs
alone are sufficient to drive at least the fundamental premise of CPGs
through.

Nico
-- 



-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444