Re: [PATCH] PAG support, try #2

["H. Peter Anvin" <hpa@zytor.com>]

Followup to:  <Pine.LNX.4.44.0305140924040.3107-100000@home.transmeta.com>
By author:    Linus Torvalds <torvalds@transmeta.com>
In newsgroup: linux.dev.kernel
> 
> And "pag_t" needs to be bigger, at least 64 bits. That, together with the
> "credential == 'list of PAG'" thing means that you can choose to do things
> like:
> 
>  - high bits zero, low bits match the UID (ie all users automatically get 
>    their own "private PAG", PAM just does the joining automatically)
> 
>    I personally _require_ this. End of discussion. Anything that doesn't 
>    allow for user-friendly automatic PAG's is, in my not-so-humble 
>    opinion, a total waste of time, and complete CRAP.
> 
>    Did I make my opinion clear enough? In other words, when I log in, I 
>    want to automatically get certain credentials, and I consider the
>    log-in sequence to be sufficient security for those credentials. 
> 
>    Anything that isn't designed for this is WRONG.
> 
>  - high bits "group pattern", low bits "GUID" - same thing as UID. Some 
>    PAG's are automatically associated with the _group_ ID of the person. 
>    When I log in, and I'm in the "engineering" group, I should
>    automatically get access to the "engineering PAG". 
> 
>  - users can controlledly join other PAGs as they wish (ie if you want to 
>    have credentials that are on top of the automatic user credentials, you
>    have to join them explicitly, which migth require a stronger password
>    or something)
> 
>    This allows for the "extra" credentials, and it also allows for users 
>    joining each others PAG's at least temporarily. It also allows things 
>    like extra groups outside of the traditional scope of groups (ie you 
>    can set up ad-hoc groups by creating a new PAG, and letting others join
>    it).
> 

Sounds like what you really want is capabilities, and not in the
setcap sense.  I think this would be marvellous, myself, and I
completely agree that we need it to be user friendly.

To some degree, groups are also capabilities, but there is too much
rigamarole surrounding them.  I also think evidence has shown that
it's too hard to add or remove group ownership; you basically need the
user to log out completely in order to add or drop the new ownerships.

	-=hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64