Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Dr. Greg Wettstein]

On May 15, 10:23am, Linus Torvalds wrote:
} Subject: Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

Good morning to everyone discussing this fascinating topic.  I've been
reading it for a day or two before joining in.  There have been some
excellent points made and I won't even try to paraphrase all of them.
I am including a snippet from what I consider the 'Linus definitive
statement' on this issue since this is the definitive focal point
which discussion must come down to.

I think the issue comes down to whether or not Linux will incorporate
functionality for the sake of correctness vs. expediency.  Based on
all the history I think that everyone generally assumes that doing
things correctly is the preferable route.

In this case doing things the 'correct' way also provide the potential
opportunity for Linux to do something reasonably creative.  I've been
banging on issues with respect to identity management and Linux since
about 1998 and it is now interesting to see these issues becoming
pragmatically relevant.

Technical thoughts follow below.

> Independent joins are a _requirement_.
> 
> My take on this is that I'm personally totally uninterested in AFS and 
> Kerberos. 
> 
> What I _am_ interested in is things like per-user VPN keys, and things
> like keeping my local harddisk encrypted.
> 
> So myt background is that unless the credentials are useful for something 
> like that, then they aren't useful AT ALL.
> 
> With a local encryption, what I'm perfectly willing to do is to go through
> a "strong authentication" once, but once I've done that, I don't want to
> do it again every time I log in to that machine. I use ssh all the time,
> and I have a few machines I trust, so when I come in from such a trusted
> machine, and the strong authentication session is already in progress, I
> don't want to see a password or anything like that. It should "just
> work".

I apologize if this solution seems somewhat off the wall but I have
been working on these issues through the Hurderos Project since about
1998.  Based on experience from lots of miles I think that solving
these issues require thinking that is somewhat out of the box.

Based on Linus' requirements it would seem that we should be thinking
about implementing something which I would refer to as an 'identity
services' cache in the kernel.  I believe that this approach would
have the advantage of satisfying Linus' vision for a solution of
grander scale while satiating the pragmatic concerns of those in the
AFS camp.

	An aside to David Howells:  I actually started a round of
	conversations with Tiemann about some of this work and these
	issues about 18 months ago.  He indicated interest but since
	then there has been nothing but a blackhole from RedHat.  I
	would be happy in working with you or anyone else that is
	interested in creative solutions in this space.

An identity services cache would essentially implement a data
structure representing the 'intrinsic' identity of each user on the
system.  Tied to this 'identity' would be data structures which would
implement multiple authentication/authorization (auth/authz) services
for the intrinsic user identity.  Put in another way these 'services'
would handle the problem of managing multiple representational
identities which is essentially what the multi-credential problem
boils down to.

In the above model a PAG essentially becomes one of many services
which are linked to the intrinsic identity of the user.  The AFS group
would simply implement a 'PAG service' which can be orthogonal to any
other representational identity, ie authentication scheme, in use by a
user.  This strategy allows AFS to continue to work within the context
of a PAG while not imposing limitations on the type or nature of any
other credentialling system.  This system is also conceptually and
notionally consistent with PAM, which would seem to be important from
the thoughts offered by Linus.

What is needed from the kernel perspective are system calls which
manage the user's intrinsic identity and the 'services' attached to
them.  The following spring to mind quickly:

	1.) Create an entry in the identity cache.

	2.) Query for and return an entry in the identity cache.

	3.) Delete an entry from the identity cache.

	4.) Create a credentials service for an identity.

	5.) Delete a credentials service for an identity.

	6.) Specify the default set of credential services that are in
	    effect for a process.

	7.) etc., etc., etc

I would envision that an entry in the identity services cache would
persist as long as there was a process that referenced the identity.

I suppose that there is the potential arguement that once an identity
was instantiated it should exist until it is explicitly destroyed.
There is probably plenty to cogitate on that issue alone.  One could
also envision instances of credential services cleaning up and
releasing themselves from their identity when something like an
expiration time was exceeded.

I would suggest that cooperativity between the credential services
would also go a long ways toward solving the joining problems and some
of the other issues that we have discussed.  Lets take classic PAG as
an example:

	Linus logs in using SSH to a server which has been configured
	to use a Kerberos PAM module.  After authentication an
	additional module checks to see whether or not his identity
	exists in the identity services cache, if not an entry is
	created.  A call is then made to attach a KERBEROS credential
	service to his identity with the credentials which were
	obtained through the authentication process.

	Later in the session he decides to view the working plans for
	the 64 bit extensions to the ix86 instruction set that
	Transmeta is working on under NDA with Intel... :-) Since the
	documents are on an AFS volume the client creates and attaches
	a PAG credential service to his identity.  During
	initialization the PAG service checks the identity cache to
	see if a KERBEROS credential service is availabe.  If so it
	either copies or links to the credentials and uses them.

	Later in the session he decides to check the work that the
	OpenAFS team is doing on the PAG service module.  He issues
	the appropriate command to obtain his credentials in the
	OpenAFS cell.  The pagsh command or whatever he uses checks to
	see whether or not a PAG service exists.  If it does it issues
	the appropriate calls to overlay his current AFS credential
	set.  Thoughout all this his credentials maintained by the
	KERBEROS identity service remain intact since AFS itself is
	only dealing with the PAG identity service.

Now this is admittedly a very contrived example but I hope it
represents the thinking behind the model.

I would be interested in any thoughts or ideas that others have on
this issue.  It is somewhat off the wall but as I mentioned before I
think that this is a case where Linus is looking for something with
large amounts of flexibility in design which doesn't lock the concept
of credential management to one particular application.

Huge amounts of detail to fill in however.

At the very minimum there will have to be defined interfaces for
various tasks that the identity services module will be expected to
offer to the kernel.  One example that comes to mind is what happens
to in various credential service types when the user wishes to change
identities.  Perhaps an even bigger question is whether or not the
seteuid() call attaches the process to the target users identity
services cache or maintains the 'real' one.

> 			Linus

I would be interested in thoughts/comments.

Best wishes for a pleasant weekend everyone.

Greg

}-- End of excerpt from Linus Torvalds

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-4950            WWW: http://www.enjellic.com
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"My thoughts on trusting Open-Source?  A quote I once saw said it
best: 'Remember, Amateurs built the ark.  Professionals built the
Titanic.'  Perhaps most significantly the ark was one guy, there were
no doubt committees involved with the Titanic project."
                                -- Dr. G.W. Wettstein
                                   Resurrection

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Jesse Pollard]

On Friday 16 May 2003 13:05, Dr. Greg Wettstein wrote:
> On May 15, 10:23am, Linus Torvalds wrote:
> } Subject: Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2
>
> Good morning to everyone discussing this fascinating topic.  I've been
> reading it for a day or two before joining in.  There have been some
> excellent points made and I won't even try to paraphrase all of them.
> I am including a snippet from what I consider the 'Linus definitive
> statement' on this issue since this is the definitive focal point
> which discussion must come down to.
>
> I think the issue comes down to whether or not Linux will incorporate
> functionality for the sake of correctness vs. expediency.  Based on
> all the history I think that everyone generally assumes that doing
> things correctly is the preferable route.
>
> In this case doing things the 'correct' way also provide the potential
> opportunity for Linux to do something reasonably creative.  I've been
> banging on issues with respect to identity management and Linux since
> about 1998 and it is now interesting to see these issues becoming
> pragmatically relevant.

There is also a (desire/need) to be able to integrate this with something
like IPSec...

In some Kerberos situations:
	1. authentication can be based on simple name/password
	2. authentication can be ased on name/password/smart card

Some sites may acctept #1 or #2. Other sites may only accept #2. (both are
related to the same realm, or cross realm operation).

> Technical thoughts follow below.
>
[Big snip]

Much of this can/should be handled outside the Kernel, PROVIDED, the kernel
can make a unique link between a process and the external security structure,
and provide communication paths between the service<=>kernel<=>app-server
("the service" is the security database server and "app-server" may be the
daemon granting login capability.

This way "the service" may make out-of-band remote requests for additional
authentication handling (translating remote credentials into local 
credentials type of thing).

It is VERY possible that a user may have been granted certain LOCAL priviliges
provided the user is NOT utilitizing unsecured networks. Or just making access
requests from unapproved locations... and still be permitted to make other
connections.

Assuming transitive privilige handling is NOT your friend (ie. undesired 
remote connection -> trusted host -> privileged access on third host).

This is slightly off the AFS line, but is spot on the "security services" that
are beginning to be discussed.

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[David Howells]

> My take on this is that I'm personally totally uninterested in AFS and
> Kerberos.

A lot of people though are interested in network filesystems (of which AFS is
but one example) and authenticating them (Kerberos is not unusual for this).

AFS itself doesn't really give a rat's backside about PAGs. They exist solely
within the client's deranged imagination as a means of coordinating sessions
between the kernel and userspace AFAICT and they are also used as a basis for
selecting cached credentials.

> What I _am_ interested in is things like per-user VPN keys, and things
> like keeping my local harddisk encrypted.

Anything that can be used for network fs's (with distributed authority
services) ought to be useful for purely local token management (where the
authority is trivial).

> So myt background is that unless the credentials are useful for something
> like that, then they aren't useful AT ALL.

I concur.

> With a local encryption, what I'm perfectly willing to do is to go through
> a "strong authentication" once, but once I've done that, I don't want to
> do it again every time I log in to that machine.

Are you requiring that the tokens be retained when you fully log out from a
machine?

> I use ssh all the time, and I have a few machines I trust, so when I come in
> from such a trusted machine, and the strong authentication session is
> already in progress, I don't want to see a password or anything like
> that. It should "just work".

I take it you're _not_ talking about transferring tokens from one machine to
another as part of the ssh login.

> And most importantly, it should "just work" _without_ having to have some
> central service have to know about it. I'm a big believer in _not_ having
> deamons that keep track of something and having to connect to them. I'm ok
> with a "ssh-agent", but I absolutely _abhor_ linkages, and if that ssh
> agent has to know about some "super-agent", and that "super-agent" has to
> talk to my "disk-agent", then you have a total disaster on your hands.

So you copy /etc/passwd around by hand every time you change your password
rather than using NIS, YP, Kerberos, SMB or whatever?

OTOH, with a large organisation with lots and lots of computers, by using
something like this a user should be able to log in anywhere, change their
password anywhere, etc without running the sysadmins ragged.

Or am I misunderstanding you? Are you talking about local daemons for keeping
hold of the tickets you've been granted by remote authorities? If that's the
case, then yes, I agree with you, but I haven't suggested such a thing is
necessary. I don't believe Kerberos, for instance, needs such a thing, but I
may be wrong.

> So I think I should be able to write a small PAM agent that automatically
> joins me with the right keys when I log in. This is my requirement. And
> part of that requirement is that my PAM agent should _not_ have to know
> about _other_ agents that may also be adding and removing keys. There
> should be no "linkages" between different key spaces, yet they should be
> able to use the same basic kernel infrastructure to maintain them.

Sort of like login reads /etc/groups to find out which groups you're in and
then calls setgroups() to load them into the kernel?

Actually, what you're describing sounds like it may have a race, but probably
not one that's significant. What happens if two login sessions for the same
user try to happen simultaneously and both immediately see that the default
keyring for that doesn't yet exist?

> And this is where naming becomes important. Because there should be no
> linkages, I think the ad-hoc naming is a bug.  My PAM module shouldn't
> have to ask somebody else what key ID's to use. It knows who I am, it
> should know where to add my keys. And it should be able to add my keys
> _without_ being in the way of somebody else adding keys.

Sounds like keyrings need names and ACLs (at the very least an owner UID).

> And when I add a key in one window, I want that key to be available in the
> other windows that were opened with independent SSH sessions. Again,
> without having to go through some super-agent to figure things out. The
> kernel _is_ the agent, and if we're adding key knowledge, we should do it
> right.

Fair enough... mostly. You still have to be able to prevent it from been added
under some circumstances.

> If I want just _one_ session to get some special powers (let's say that I
> do the equivalent of "su", except I do it by adding the proper credentials
> to my session instead of by changign to root user), then I should be able
> to just do
>
> 	new-session	/* creates a new local keyring at the top of the
> 			   credentials stack */
> 	add-key xxxx	/* adds a new key to the top keyring - and because
> 			   the top keyring now isn't my default one, other
> 			   ssh sessions won't be seeing this key */
>
> but if I do _just_ the
>
> 	add-key xxxx
>
> then I want that key to show up in all my other sessions too, because now
> I'll be adding a key to my "default session". And it also shows up in the
> window where I have even _more_ capabilities - the "new-session" didn't
> drop my old capabilities, it just created a space to hold even more
> (independent) keys.

Hmmm... Do you envision a strict stack? Or a manipulatable sequence? Take a
SUID program for instance, do you want the SUID credentials to override the
pre-exec credentials until discarded (at which point there's no way to
retrieve them)? Or do you envision the following "commands":

 (*) new-session <name> [<ACL>]

     Create a new private keyring or session, potentially with ACL governing
     joining, modification, etc. by users and/or groups.

 (*) list-sessions <name>

     List keyrings available to this process

 (*) list-keys <name>

     List keys in the available session

 (*) upgrade-session <name>

     Move session to front of sequence. Becomes provider of UID/GID for
     this process.

 (*) add-key [--session <name>] <data>

     Add a key to the primary or named session.

David

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Nathan Neulinger]

> If you make PAG id's permanent, then you have to make them
> visible (*1).  You have to manage them.  You have to be able
> to look them up (ie, "give me pag #5").  You have to have
> them unique across multiple machines, where those machines
> will also span multiple administrative domains.  You have to
> add passwords to them.  You will make them much much heavier
> weight, and I really don't see all that much advantage from
> that adding that extra weight and complexity.

Currently they are visible, but it's considered opaque and really isn't
of use to anything other than administrative tools (for the local
system).

> Note that if you did have join-able PAG's, it would not be
> based on the userid who first authenticated to it.  We have
> people who use a shared account for access to local (unix)
> files, and then klog to separate AFS user accounts.  Personally
> I don't like that, but I either accept it or get a new job.
> 

> So, if you're going to have joinable PAG's, then you need to
> attach some password/authentication method which is specific
> to that PAG, and not related to any of the tokens which have
> been used in that PAG.
> 
> 

Joinable pags is a purely administrative function, used by almost nobody
right now except for a few esoteric system admin functions on select
installations, certainly nothing in a normal install/setup.

If that capability is objectionable (most people didn't even realize it
was possible currently, and at that, only for root/suid=0 procs)

> In fact, you could think of a PAG as just being an automatic
> way to have an ssh-agent -- and an ssh-agent which did not
> depend on keeping those environment variables set correctly.
> When using ssh, I start up an ssh-agent in one window, and
> then copy the environment variable-settings to all my other
> unix windows.  That's because they have separate environments
> (and because I'm too lazy to do something more intelligent
> in my .bashrc file).  I also have to hope that if I run
> process X, and process X runs process Y, that the ssh-agent
> variables are correctly passed through to process Y.
> 
> But as far as AFS is concerned, I just 'klog drosehn' in one
> window, and all my session-related processes immediately have
> that access.  No need to track them down and change
> environment variables in them.  No need to start the ssh-agent
> before starting the GUI-ish applications.  No worries about
> processes not-passing along environment variables to other
> processes that they start.  This all works fairly well, in
> my experience.  In fact, I honestly wish I could get the
> ssh-userids tied to a PAG, instead of an environment variable.

And more importantly - that behavior is totally expected across ALL
on-the-same-system activities by AFS users. We expect that we're not
going to get new pags assigned except at explicit request or expected
times, and that includes copying tokens/tickets/etc. 

If I run a subshell/suid app/etc. and klog/kinit to get new
tokens/keys/whatever, I expect that those keys will be available to the
parent process and all other processes in that same pag. If I don't want
this behavior, I'll request a new pag before starting the
subshell/app/whatever. AFS cmd line tools make this real easy "pagsh
cmd". 

It would be best if y'all would avoid trying to combine the issue of
PAGs with the issue of auth/key/token/ticket data in the kernel. They
are orthogonal to each other. 

I've also seen numerous mentions of the fact that afs can only deal with
a single token per cell per pag. This shouldn't be of issue to the PAG
discussion at all - it's up to the individual filesystem to handle how
it accepts token data into the kernel. The only thing that is decided
for it is what PAG the data is associated with.

Additionally - why all this worry/concern about sharing keys. Yuck. If
we want multiple separate pags authenticated to the same entity, we'll
just insert the tokens more than once from user space. No reason to
concern the kernel with that.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Peter Chubb]

>>>>> "chas" == chas williams <chas@locutus.cmf.nrl.navy.mil> writes:

chas> In message <6445.1053005715@warthog.warthog>,David Howells
chas> writes:
>> Where's this 1:1 come from? PAGs aren't 1:1 with processes, nor are
>> they 1:1 with users.
>> 
>> I've tried to implement them as I understand the design information
>> I could find (which specified that any process could belong to a
>> single PAG). From the comments that have been made, it seems that
>> each user needs some sort of fallback token set for any process
>> that doesn't have a PAG.

chas> PAGs shouldnt be 1:1 with processes or users.  They are closer
chas> in nature to process groups.  However, a process wouldnt loose

PAGs as you describe them are beginning to sound like a Cray `job',
although used for a different purpose.

Each process had a jobid in addition to its other IDs.  This was set
at login or by NQS (or by a few other privileged processes), initially
identical to the session ID.  After that, setsid(), setpgid(),
setpgrp() etc., would not change the job ID.

The job ID was used for accounting and resource managemment, IIRC.

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories,   all slightly different.

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Garance A Drosihn]

Advance disclaimer: I have no idea what you do or do not know
about how AFS works, so this may explain some things that you
don't really need explained.  Apologies if that's true...


At 7:30 PM -0700 5/14/03, Linus Torvalds wrote:
>On 15 May 2003, Trond Myklebust wrote:
>>
>  > The interesting thing about a PAG is that it is a handle
>  > that is shared between userland and the kernel, and carries
>  > information about which collection of authentication
>  > tokens/credentials a process holds.
>
>I agree. However, I think that the PAG namespace should be
>bigger than the uid namespace, so that you can have a mapping
>from uid to the PAG.

Actually, it is perfectly fine for the pag name space to be
smaller than the uid name space.  In fact, by definition that
is true.  A single pag can hold the tokens of users for multiple
cells at the same time, so I can be both drosehn@rpi.edu and
gad@umich.edu at the very same moment.  It's just that I can not
be drosehn@rpi.edu and drosehn_a@rpi.edu (my "super AFS account")
at the same moment.

So, technically, my userid space is the space of all userids
from all AFS cells.  There is nothing that says I have to
authenticate as gad@rpi.edu -- and in fact I don't.  There
is no "gad@rpi.edu", even though I use 'gad' as my unix userid
on my own workstation.  I log in as gad, which gives me a PAG
with no credentials, and later on I authenticate to userid
drosehn@rpi.edu.  I could just as well authenticate to userid
gad@umich.edu (well, I could if I still had a userid there...).

The range of PAG id's only has to be as large as the range
of simultaneous processes on any given machine.  (So that
each process could have it's own pag, if it wanted to).  This
does mean that it is true you might very well want different
ranges for a PAG on different machines.

On the other hand, I should note that I don't really care what
range is used for PAG values, just as long as PAGs work the
right way.  If someone wants 64-bit pag's, well, that probably
should not hurt too much.  Hopefully the guys who do the real
work on openafs won't kill me for saying that!

>Also, I _know_ there are situations where you want to share
>credentials _without_ sharing "everything". That's why the
>unix notion of "group" exists, after all. And there is a good
>reason why people can be members of  multiple groups at once.

AFS also has groups.  When it comes to permitting files, AFS has
a much more flexible idea of groups than the standard unix group.
You can a specific directory, and set explicit access to a variety
of explicitly-specified groups.

Eg:
    (20) fs listacl ~/cis
    Access list for /home/37/drosehn/cis is
    Normal rights:
      drosehn:itsmisc rl
      its:etgroup rl
      its:unixprogs rl
      system:backup l
      its:operators rl
      its:wsg rl
      its rl
      system:administrators rl
      drosehn rlidwka

Everything in that list is a group, except for that last entry.
Note that the "group" value as listed for that directory is
totally irrelevant to that access.  In AFS, you do not "set
the one-and-only group" for the file.

As you say, any single AFS user can be a member of any number
of AFS groups.  That issue is handled quite well by AFS.

>  > RPCSEC can be made to use it to communicate which bag of
>  > creds the userland daemon may use when it attempts to
>  > negotiate a new security context for an NFS user.
>
>Absolutely. I just think it should be taken a step further.
>
>Right now the limited PAG namespace as implemented by the
>current patch means that a PAG ID number _has_ to be
>throw-away: the namespace is too small to give users
>permanent PAG ID's.

If you make PAG id's permanent, then you have to make them
visible (*1).  You have to manage them.  You have to be able
to look them up (ie, "give me pag #5").  You have to have
them unique across multiple machines, where those machines
will also span multiple administrative domains.  You have to
add passwords to them.  You will make them much much heavier
weight, and I really don't see all that much advantage from
that adding that extra weight and complexity.

Right now, the creation of a PAG should be an almost zero-cost
option.  The implementation-work is just that PAGS have to be
kept track of separately from processes and userids.  You can
change pags without changing your process or userid, and you
can change userids and processes without losing the pag you
are in.  Both of those need to be true.

*1 = While we talk about PAG values here, I should note that
as a user I have never had any idea of the exact value of
any PAG I have had.  Not once.  I don't even know how to get
the value if I did want it.  All I care about is what tokens
are in my PAG, and when those tokens will expire.

>That's fine per se: you can always create a mapping layer in
>some outside-of-the-kernel way (ie a database of
>"user -> currently used PAG space"),

There is no mapping that goes from a userid to a currently-used
pag space.  At least, I do not know of one.  Somehow we've used
AFS for more than ten years without ever needing that information.

I'm sure it could be done, I just haven't had a need for it.

>So the PAG namespace thing is really just a detail, but one
>which I think is indicative of how this thing would be used
>in practice.

All I can try to do is explain how openafs does in fact use
PAG's, and that in practice it has been a very useful concept.

>But especially if the keys are based off some private user
>knowledge (ie a master session password required to initiate
>the first session), you most likely _do_ want a "join"
>operation that is able to take advantage of the fact that
>the user has already logged in once, and now just wants to
>create a new session - without having to keep the password
>around on the client.

Note that if you did have join-able PAG's, it would not be
based on the userid who first authenticated to it.  We have
people who use a shared account for access to local (unix)
files, and then klog to separate AFS user accounts.  Personally
I don't like that, but I either accept it or get a new job.

More plausibly, different people might log in as one user in
the RPI cell, and then also authenticate as other userids in
any number of other AFS cells.  As far as RPI is concerned,
that pag is still origuser@rpi.edu, but that does not mean
that anyone who knows the password to origuser@rpi.edu will
also have rights to all those AFS userids from other sites.

So, if you're going to have joinable PAG's, then you need to
attach some password/authentication method which is specific
to that PAG, and not related to any of the tokens which have
been used in that PAG.

>In other words, I think of the credentials of equivalent to
>the private keys that something like "ssh-agent" keeps around.
>But different connectors may want to have different disjoint
>sets of keys. Which is again why I think we want to have
>multiple PAG ID's per process.
>
>And the reason I'd like to have the "uid -> default PAG"
>mapping is that that one ends up being somewhat similar to
>the "SSH_AGENT_PID" environment variable for that user. You
>can have multiple PAG's (or none), but I envision one being
>set up for you by default. And you need _some_ key to access
>that default PAG. And the obvious key to use is, to me, the
>already existsing "uid".
>
>Do I make sense?

Well, I seem to agree with so much of what you're thinking,
and then you bring up an analogy that just loses me.  I keep
thinking that we would completely agree, if I can just bring
the PAG situation into focus with the right analogy.

I can see that the idea of a joinable PAG could be of use in
some circumstances, but I really think the overhead of doing
a truly-accurate implementation of that would be too expensive
for too little benefit.  And I also think that in practice
there would be very little need and very little use of
joinable PAGs.  I don't see the point in adding a lot of
expense for something that would rarely be useful.

In your ssh-agent analogy, note that any given process will
have only one ssh-agent.  That agent may have any number of
ssh keys, but you're either using ssh-agent #3 or #4, you
can never be using both #3 and #4.  I would argue that PAG's
are much closer to that ssh-agent process.

In fact, you could think of a PAG as just being an automatic
way to have an ssh-agent -- and an ssh-agent which did not
depend on keeping those environment variables set correctly.
When using ssh, I start up an ssh-agent in one window, and
then copy the environment variable-settings to all my other
unix windows.  That's because they have separate environments
(and because I'm too lazy to do something more intelligent
in my .bashrc file).  I also have to hope that if I run
process X, and process X runs process Y, that the ssh-agent
variables are correctly passed through to process Y.

But as far as AFS is concerned, I just 'klog drosehn' in one
window, and all my session-related processes immediately have
that access.  No need to track them down and change
environment variables in them.  No need to start the ssh-agent
before starting the GUI-ish applications.  No worries about
processes not-passing along environment variables to other
processes that they start.  This all works fairly well, in
my experience.  In fact, I honestly wish I could get the
ssh-userids tied to a PAG, instead of an environment variable.

Well, anyway, has this long rambling explanation been of any
help?

-- 
Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Linus Torvalds]

On Thu, 15 May 2003, David Howells wrote:
> > 
> > No it isn't. You can't do independent joins, since as it is, the code has
> > an "all or nothing" approach.
> 
> Independent joins aren't necessarily good either. They add lots of complexity
> and consume lots of kernel resources.

Independent joins are a _requirement_.

My take on this is that I'm personally totally uninterested in AFS and 
Kerberos. 

What I _am_ interested in is things like per-user VPN keys, and things
like keeping my local harddisk encrypted.

So myt background is that unless the credentials are useful for something 
like that, then they aren't useful AT ALL.

With a local encryption, what I'm perfectly willing to do is to go through
a "strong authentication" once, but once I've done that, I don't want to
do it again every time I log in to that machine. I use ssh all the time,
and I have a few machines I trust, so when I come in from such a trusted
machine, and the strong authentication session is already in progress, I
don't want to see a password or anything like that. It should "just work".

And most importantly, it should "just work" _without_ having to have some 
central service have to know about it. I'm a big believer in _not_ having 
deamons that keep track of something and having to connect to them. I'm ok 
with a "ssh-agent", but I absolutely _abhor_ linkages, and if that ssh 
agent has to know about some "super-agent", and that "super-agent" has to 
talk to my "disk-agent", then you have a total disaster on your hands. 

[ It's a total disaster that a lot of CS'y people like, with indirect 
  servers keeping track of other servers that actually do the keys, but I
  think it's all complete crap. Once the kernel knows about the keys, you 
  shouldn't need that kind of indirection on the local machine. ]

So I think I should be able to write a small PAM agent that automatically 
joins me with the right keys when I log in. This is my requirement. And 
part of that requirement is that my PAM agent should _not_ have to know 
about _other_ agents that may also be adding and removing keys. There 
should be no "linkages" between different key spaces, yet they should be 
able to use the same basic kernel infrastructure to maintain them.

And this is where naming becomes important. Because there should be no 
linkages, I think the ad-hoc naming is a bug.  My PAM module shouldn't 
have to ask somebody else what key ID's to use. It knows who I am, it 
should know where to add my keys. And it should be able to add my keys 
_without_ being in the way of somebody else adding keys.

And when I add a key in one window, I want that key to be available in the 
other windows that were opened with independent SSH sessions. Again, 
without having to go through some super-agent to figure things out. The 
kernel _is_ the agent, and if we're adding key knowledge, we should do it 
right.

If I want just _one_ session to get some special powers (let's say that I 
do the equivalent of "su", except I do it by adding the proper credentials 
to my session instead of by changign to root user), then I should be able 
to just do

	new-session	/* creates a new local keyring at the top of the 
			   credentials stack */
	add-key xxxx	/* adds a new key to the top keyring - and because
			   the top keyring now isn't my default one, other
			   ssh sessions won't be seeing this key */

but if I do _just_ the

	add-key xxxx

then I want that key to show up in all my other sessions too, because now 
I'll be adding a key to my "default session". And it also shows up in the 
window where I have even _more_ capabilities - the "new-session" didn't 
drop my old capabilities, it just created a space to hold even more 
(independent) keys.

If your thing can't do this, then I'm not interested. And the patch I've 
seen so far can't do it.

			Linus

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[David Howells]

> > Pardon me if I'm wrong, but doesn't the PAG already allow for multiple
> > credentials?
> 
> Yes, but the patch did not allow for
> 
>  -  partial sharing (keys are bound to _one_ PAG, and one PAG only)
> 
>     This makes "revoke" pretty much useless, since you have a damn hard 
>     time finding all the keys, since you have to copy them around instead 
>     of sharing one instance.

Okay, so separate PAG IDs and credentials. Have a separate credential cache
to which the PAG ID is but one of the keys, then share entries that have a
common (remote-user-ID,fsname,domain) key.

>     It also makes grouping very hard. 

Grouping is superfluous and not trivial at any time. Use ACLs.

>  - the name space is so limited that you _have_ to consider the PAG ID's 
>    temporary, which means that you have to add a whole new layer of 
>    maintenance in user space.

PAG IDs _are_ ephemeral.

> Neither of these are apparently problems in the AFS world, because there 
> is only one entity that gives out keys, so that one entity can keep track 
> of every key ever allocated.

That's not exactly so (see next comment).

> But look at the big picture. What happens when you have multiple sources 
> of keys that have nothing to do with each other.

Like AFS, you mean? Each AFS cell (or cell group) may contain an independent
kerberos server that dispenses keys that are nothing to do with the kerberos
tickets granted by another cell.

For instance, the openafs.org cell my grant me a ticket for accessing there,
but that wouldn't be any use for redhat.com or cambridge.redhat.com
cells. Whereas the redhat kerberos server might grant me a ticket that'd
permit me to access either redhat cell.

> How do you maintain sanity in that kind of world, when the numbers don't
> have any meaning, and one of the key maintainers doing a "join" operation
> will throw away all the work that the other key maintainers did.

Assuming there is a join operation. I think setpag() should go, leaving only
newpag().

> >	  Linus seems to be arguing for multiple PAGs, like multiple
> > GIDs. But I think that functionality is really there, inside the PAG.
> 
> No it isn't. You can't do independent joins, since as it is, the code has
> an "all or nothing" approach.

Independent joins aren't necessarily good either. They add lots of complexity
and consume lots of kernel resources.

> Again, this works in a single-use environment, where there is central 
> control. It _sucks_ if you want to have a generic "bunch of keys" model.

I've tried to make my PAG patch support a multi-use environment.

David

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Linus Torvalds]

On Thu, 15 May 2003, Dean Anderson wrote:
>
> Pardon me if I'm wrong, but doesn't the PAG already allow for multiple
> credentials?

Yes, but the patch did not allow for

 -  partial sharing (keys are bound to _one_ PAG, and one PAG only)

    This makes "revoke" pretty much useless, since you have a damn hard 
    time finding all the keys, since you have to copy them around instead 
    of sharing one instance.

    It also makes grouping very hard. 

 - the name space is so limited that you _have_ to consider the PAG ID's 
   temporary, which means that you have to add a whole new layer of 
   maintenance in user space.

Neither of these are apparently problems in the AFS world, because there 
is only one entity that gives out keys, so that one entity can keep track 
of every key ever allocated.

But look at the big picture. What happens when you have multiple sources 
of keys that have nothing to do with each other. How do you maintain 
sanity in that kind of world, when the numbers don't have any meaning, and 
one of the key maintainers doing a  "join" operation will throw away 
all the work that the other key maintainers did.

>	  Linus seems to be arguing for multiple PAGs, like multiple
> GIDs. But I think that functionality is really there, inside the PAG.

No it isn't. You can't do independent joins, since as it is, the code has
an "all or nothing" approach.

Again, this works in a single-use environment, where there is central 
control. It _sucks_ if you want to have a generic "bunch of keys" model.

		Linus

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Douglas E. Engert]

Garance A Drosihn wrote:

> 
> There is ZERO connection between login ids and PAG numbers.  It
> is entirely for tracking "sessions".  If I am on one machine and
> ssh into another one, the session on the remote machine will be
> one PAG.  If I ssh into the exact same userid a second time, it
> will get a second PAG.  There is absolutely no reason for the
> second session to have the slightest idea of what PAG the first
> session is using.  It's like saying "the second session has to
> know the pid of the first process of the first session".  This
> is just a false idea of what the PAG is tracking.
> 
>

I disagree. From the user's perspective, what they might call a session
does not require a process to be keep active. It does not have to
depend on a connection to be kept active either. They may want to 
stage credentials, then come back later with a new connection then use
these credentials.  They might wish to use multiple TCP connections
to the same machine, and have them be considered a session.   

The point is how can this be done, and can the OS assist in this at all.
Is the PAG the way to identify this, or is the PAG a kernel only concept
which is associated with active processes and sub processes. 

Traditionally, the session was defined by the process started for the user
and its sub processes when a network connection or key board login was
started.     

Also traditionally with some systems, the user could stage credentials,
i.e. the Kerberos ticket cache in /tmp owned by the user, so subsequent
connections by the same user could use the previous ticket cache, and 
the user could continue his session. 

With AFS the token was in the kernel, and not stored where the user
could come back and use it later, thus requiring the acquisition of 
a new token at each connection. But the AFS token was not a lot of 
overhead to acquire. 

But DCE/DFS got more complicated, as there might be more tickets, 
one for each file server, and there were the PTGTs as well with group
info. They tied the name of the credential file to the PAG number used
by the kernel, thus they did not have this capability either,
unless the files where copied, or you could join the existing DFS 
PAG if it was still active in the kernel. 

SSL session caching is a good example. After the initial session was 
established, the web server can hold on to the SSL session info, so 
that if the  same user connects again with a separate SSL session, but 
can use the same session key, the certificate verification process does 
not need to be done again. Thus avoiding a lot of overhead. How can you do 
something similar be done in a more general fashion by the OS. 


> 
> --
> Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
> Senior Systems Programmer           or  gad@freebsd.org
> Rensselaer Polytechnic Institute    or  drosih@rpi.edu
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

-- 

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

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Booker Bense]

On Wed, 14 May 2003, Linus Torvalds wrote:

>
> On Wed, 14 May 2003, Russ Allbery wrote:
> >
> > If a single process is in possession of multiple sets of credentials at
> > the same time, how does the file system code in the kernel know which ones
> > to use for a given operation with a network file system?
>
> The file system code will have to make up its own mind about it.

- How? The only way I can see is by trying them all...

>
> In particular, it's likely the case that only _one_ credential is valid
> for that particular mount anyway. You have to ask yourself: where did
> these keys all _come_ from in the first place? And the answer is: usually
> the filesystem. The key was used and registered at mount-time (encrypted
> filesystem), or by some filesystem-specific key exchange.

- This is definitely not the case with AFS or any other
distributed filesystem that I know about. I think the semantics
of encrypted filesystems vs. distributed ones are different
enough that you are going to have problems supporting both with
the same tool. Even if there is a key exchange/auth at mount, you
will still require additional per user key information in a
multi-user file system.

>
> So I expect that for many filesystems there will never be any confusion.
> Clearly AFS only expects to have one session PAG, for example (since that
> is how the _current_ AFS stuff wants to do it), and that implies that
> whenever that session PAG is instantiated, the code that instantiates it
> will remove any old stale PAGs.
>
> But the fact that you'd have AFS with just one set of credentials doesn't
> mean that the same process might not want to have another PAG for other
> uses. Each use might only fit one way.

- You still don't seem to grok what a PAG is. It's merely a
pointer to WHERE to look for credentials, it says nothing about
how many or what kind you'll find there. You can change
credentials without changing your PAG.

>
> And even when you have multiple PAG's for the same entity, this is not a
> new situation. In fact, UNIX pretty much since day 1 has had it: what do
> you think user/group/other are? They are prioritized credentials. There,
> you have two different credentials (well, groups are multiple ones in
> themselves), with a prioritation scheme ("user matters more, but if user
> doesn't match there is no prioritation in groups _except_ one group entry
> is special in that we'll use that for new ID creation").
>
> Up to the filesystem to decide what it does with the different
> credentials, in other words. Some filesystem may decide to only allow one.

- The question is still "WHICH ONE?" How does it decide? Look at
them all? If you've got two valid ones how does it decide?

- I think you're confusing the current implementation of PAG's
which is admitted a hack a best with the idea of PAG's. It'd be
really nice to have kernel with a sane implementation of
setpag/getpag.

_ Booker C. Bense

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Dean Anderson]

Pardon me if I'm wrong, but doesn't the PAG already allow for multiple
credentials?  Linus seems to be arguing for multiple PAGs, like multiple
GIDs. But I think that functionality is really there, inside the PAG. It
seems to me (somewhat) that there is really violent agreement, but varying
terms.

		--Dean

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[chas williams]

In message <6445.1053005715@warthog.warthog>,David Howells writes:
>Where's this 1:1 come from? PAGs aren't 1:1 with processes, nor are they 1:1
>with users.
>
>I've tried to implement them as I understand the design information I could
>find (which specified that any process could belong to a single PAG). From the
>comments that have been made, it seems that each user needs some sort of
>fallback token set for any process that doesn't have a PAG.

PAGs shouldnt be 1:1 with processes or users.  They are closer in nature
to process groups.  However,  a process wouldnt loose its PAG affiliation
after calling setsid.  This is the main reason using the process group
isn't sufficient for PAGs.

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[David Howells]

> >      For any process where pag != 0, that process will share
> >      tokens with all other processes that have the exact same
> >      pag value as it has.  This is true even if the different
> >      processes are tied to different user ids.
> 
> Yeah, and the thing I think it _totally_ and utterly broken is that there 
> can be only one of these per process.
>
> I don't see where the 1:1 idea comes from, except from a bad 
> implementation.

Where's this 1:1 come from? PAGs aren't 1:1 with processes, nor are they 1:1
with users.

I've tried to implement them as I understand the design information I could
find (which specified that any process could belong to a single PAG). From the
comments that have been made, it seems that each user needs some sort of
fallback token set for any process that doesn't have a PAG.

> > There is absolutely no connection between userids and PAG's,
> > the same way that there is no connection between userids and
> > process-numbers.  (Roughly speaking:) The 10th person to log
> > in will get the 10th pag, no matter what userid they happen
> > to log in as.
> 
> And this is also again nothing but the result of a bad implementation.

That's the design.

Since AFS uses the PAG as part of the lookup key, it seemed reasonable to make
a more formal association between the credential ring and the PAG in the
kernel (especially as I needed someway of (a) generating a unique PAG, and (b)
performing garbage collection on PAGs).

> From a system maintenance issue, this is a nightmare. It makes joining a 
> group nigh impossible, since now the joiner (login or something) has to 
> keep track of what pag's it has used for previous logins. Which is fine as 
> long as you have _one_ login authority, but it's a total disaster to 
> require that kind of centralization.

Adding credentials to groups seems to be tricky (if not superfluous - surely
that's what ACLs are for).

Who should add creds to groups? And assuming like kerberos is used, wouldn't
the lifetime a credential attached to a group then be dependent in some way on
the authorisation granted to the user who requested the group cred in the
first place?

It's also not a total disaster to have a central login authority (assuming I'm
understanding your objection correctly). It's necessary for many reasons
(including distributed filesystems), and is supported any many ways: kerberos,
YP/NIS, M$ SMB, LDAP.

It seems to me that what is required is a ring of tokens, each of which says:

	When accessing data in domain "A" using protocol "B", present myself
	as user "C" using credential "D" from authority "E".

Then the servers in domain "A" say:

	User "C" is trying to read datum "F". I validated his/her presented
	credential against "E". Datum "F" may be accessed in certain ways by
	users "G" and "H" and the members of groups "I", "J" and "K". Aha!
	User "C" is in group "J", and members of "J" are allowed to read "F",
	write "F" and turn "F" into a can of spam. Okay, "C" is allowed to
	read it.

But what do you do for a group credential?

	When accessing data in domain "A" using protocol "B", present myself
	as group "J" using credential "D" from authority "E".

This isn't good - if group management is handled on the client, the server
then has to be able to trust the client absolutely.

You could add a credential to a group so that users accessing files in a
particular domain do so as a special user (use the user "engineering" for
example when accessing files in devel.redhat.com), but I suspect that sort of
thing isn't really what you want. I think that what you want there is ACLs.

Furthermore, I think a process's gid and groups[] are something of a dead
herring in this respect. They are a primitive ACL-like mechanism that's fine
for UNIX local filesystems (in which case the kernel acts as its own
authority), but don't necessarily map to network filesystems (though they are
used by NFS/RPC doing AUTH_UNIX).

Furthermore, PAGs and your group rings ought to self-destruct when nobody is
referring to them as they consume kernel resources.

> Right now the limited PAG namespace as implemented by the current patch
> means that a PAG ID number _has_ to be throw-away: the namespace is too
> small to give users permanent PAG ID's.

PAG IDs are designed to be throw-away.

> That's fine per se: you can always create a mapping layer in some
> outside-of-the-kernel way (ie a database of "user -> currently used PAG
> space"), but it's so much easier - I think - to just make the name space big
> enough that you can have a trivial static mapping "user -> permanent PAG
> ID".

You'd still need the outside-of-the-kernel database or whatever. Otherwise,
what would the ID numbers mean? After all, how do you know which UID number
corresponds to your account?

The ability to join PAGs is mostly unnecessary, it's just that it seems the
facility is useful for a few specialised purposes (NFS->AFS translator being
the primary one IIRC), and could possibly be dispensed with.

It may be worth doing three things to my patch:

 (1) Discard setpag(pag_t).

 (2) Make pag_t either unsigned long (though this may cause problems when
     running a 32-bit program on a 64-bit arch) or unsigned long long and
     returned through a dereferenced pointer.

 (3) Add a default PAG to every struct user and add a syscall to attach the
     process to this PAG instead of what it is currently using.

Though I don't expect you'll agree to that.

It's not that I'm particularly attached to PAGs, it's just that they're a
simple way of doing what I require.

David

RE: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Garance A Drosihn]

At 7:04 AM +0100 5/15/03, Riley Williams wrote:
>Hi Russ.
>
>  > If a single process is in possession of multiple sets of
>  > credentials at the same time, how does the file system code
>  > in the kernel know which ones to use for a given operation
>  > with a network file system?
>
>I am in possession of multiple sets of credentials - my driving
>licence, my passport, my works pass, my bank cards, my store
>cards, to name just a few. How does the entity I am interacting
>with know which one they are interested in, I wonder...

You have this analogy at the wrong level.  I must admit that I
have not looked at the code which everyone is discussing, so
maybe it is the code which is confusing people who have not
dealt with a PAG before.

Yes, you (as a person) have multiple credentials, but they are
from different "cells".  A PAG can contain multiple credentials
from different AFS cells, but it can only contain one credential
from any one cell.  So, for instance, you have a driver's license,
and a dozen other cards.  However, if the police pull you over and
you hand them two different driver's license from the same state,
and those licenses have different names, and you say "I am both of
these people", then you are probably going to find yourself in
some pretty serious trouble.

The credential we're talking about here is your AFS userid (that
is the credential which is stored in a PAG --> NOTE that it is
*not* the pag itself, the pag is just a collection of credentials).
So, having multiple AFS userids from a single cell at the same
moment is exactly the same as saying a single process is two
different unix userids at the same moment.

Please realize that actually I'd love to have a way to be two
AFS userids at the same moment, and one might get some ideas
from the unix notion of setuid() vs seteuid().  But that is
the set of questions that you'd need to answer if you want a
single PAG to hold more than one token-from-a-single-cell at
the exact same moment.  Some process is going to open a single
file, and it will have to make access-checks when opening that
single file, and you want those access checks to see "two
different people" at the same moment -- even though those two
people may have explicitly different access to the file.

>Best wishes from Riley.

Best wishes in return.  Cheerio.

Unfortunately I'm late for meeting right now, so I have to run.
I should be back in, uh, about eight or nine hours.  I hate days
like this...

-- 
Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Garance A Drosihn]

At 5:57 PM -0700 5/14/03, Linus Torvalds wrote:
>On Wed, 14 May 2003, Garance A Drosihn wrote:
>>
>>       For any process where pag != 0, that process will share
>>       tokens with all other processes that have the exact same
>>       pag value as it has.  This is true even if the different
>>       processes are tied to different user ids.
>
>Yeah, and the thing I think it _totally_ and utterly broken is
>that there  can be only one of these per process.
>
>I don't see where the 1:1 idea comes from, except from a bad
>implementation.

Well, personally I would not mind the idea of multiple tokens
for a given AFS cell in a single PAG, but that does brings up
a number of extra implementation problems.  I would be happy
if the linux-implementation of PAG's *allowed* for multiple
tokens-from-a-single-cell, but that we (afs) started out by
still using only one.   Note that a PAG can already contain
multiple AFS tokens, it's just that each token would have to
be from a different AFS cell.  Allowing for multiple
tokens-from-a-single-cell would mean that you would be two
different AFS users at the same time.

Mind you, there are definitely times that I would like that!
But it means you have to answer the same kinds of questions
that you would need to answer if a single unix process was
two different unix uid's at the exact same time.  What if one
userid has explicit access to a file, and the other userid
is explicitly listed as having absolutely no access to the
same file?

>  > There is absolutely no connection between userids and PAG's,
>>  the same way that there is no connection between userids and
>>  process-numbers.  (Roughly speaking:) The 10th person to log
>>  in will get the 10th pag, no matter what userid they happen
>>  to log in as.
>
>And this is also again nothing but the result of a bad
>implementation.
>
>From a system maintenance issue, this is a nightmare. It makes
>joining a group nigh impossible, since now the joiner (login
>or something) has to keep track of what pag's it has used for
>previous logins. Which is fine as  long as you have _one_
>login authority, but it's a total disaster to  require that
>kind of centralization.

You are still thinking about this the wrong way, although that
is probably because I was too terse.  (me? too terse? who would
have thought?).  What I meant was more "the 10th person to log
in after a system reboot will get the 10th pag".  In this sense,
a PAG is *exactly* the same as a process ID.  It is only a value
that is unique across a single machine at any given moment.  Once
you reboot a machine, you can start back at PAG #1 (so to speak).
The PAG #1 which existed before the reboot will have absolutely
no relation to the PAG #1 which exists after the reboot.

There is ZERO connection between login ids and PAG numbers.  It
is entirely for tracking "sessions".  If I am on one machine and
ssh into another one, the session on the remote machine will be
one PAG.  If I ssh into the exact same userid a second time, it
will get a second PAG.  There is absolutely no reason for the
second session to have the slightest idea of what PAG the first
session is using.  It's like saying "the second session has to
know the pid of the first process of the first session".  This
is just a false idea of what the PAG is tracking.

>  > It's tokens which have some relation to userids.  In the world
>>  of AFS, a pag can hold only one token from any one AFS cell
>>  at a given time.  But I can change which "AFS userid" that I
>>  am, without changing which pag I am in, and all processes in
>>  that same pag will instantly become that same "AFS userid".
>
>Yes. And apparently PAG's - as you see them - are nothing but a
>AFS issue.   As such, I think they are totally uninteresting for
>the core kernel, and I will _not_ be applying any patches that
>introduce such a limiting and stupid notion into the core kernel.

I am hoping that if we can get an accurate picture of PAG's, they
will appear much more generally usable.

>I'm interested in a much more generic issue of "user credentials",
>and here a PAG can be _one_ credential that a user holds on to.
>But to be  useful, a user has to be able to have multiple such
>credentials. While one  might be his "AFS userid", another will
>be his NFS mount credentials, and  a third one will be his key
>to decrypt his home directory on that machine.
>
>If it's useful for AFS only, I'm not interested.

I think the concept should be usable for other contexts, too.

A PAG is not a "credential", it is what you would connect
credentials to.  It is not a collection of "user credentials", it
is a collection of "session credentials", where your AFS userid
is just one credential in that collection.  Instead of connecting
credentials to a userid, or a groupid, a PAG is just adding the
new notion of a "session id".  The one difference between this
"session id" and userids is that you don't "join" a session, any
more than you would "join" a process-id.

Any process can get a new PAG and thus change from their current
PAG to some new PAG, but they can not "join" any PAG that already
exists.

-- 
Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Linus Torvalds]

On Wed, 14 May 2003, Russ Allbery wrote:
> 
> If a single process is in possession of multiple sets of credentials at
> the same time, how does the file system code in the kernel know which ones
> to use for a given operation with a network file system?

The file system code will have to make up its own mind about it. 

In particular, it's likely the case that only _one_ credential is valid 
for that particular mount anyway. You have to ask yourself: where did 
these keys all _come_ from in the first place? And the answer is: usually 
the filesystem. The key was used and registered at mount-time (encrypted 
filesystem), or by some filesystem-specific key exchange.

So I expect that for many filesystems there will never be any confusion.  
Clearly AFS only expects to have one session PAG, for example (since that
is how the _current_ AFS stuff wants to do it), and that implies that
whenever that session PAG is instantiated, the code that instantiates it
will remove any old stale PAGs.

But the fact that you'd have AFS with just one set of credentials doesn't
mean that the same process might not want to have another PAG for other 
uses. Each use might only fit one way. 

And even when you have multiple PAG's for the same entity, this is not a
new situation. In fact, UNIX pretty much since day 1 has had it: what do
you think user/group/other are? They are prioritized credentials. There,
you have two different credentials (well, groups are multiple ones in
themselves), with a prioritation scheme ("user matters more, but if user
doesn't match there is no prioritation in groups _except_ one group entry
is special in that we'll use that for new ID creation").

Up to the filesystem to decide what it does with the different 
credentials, in other words. Some filesystem may decide to only allow one.

			Linus

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Russ Allbery]

Linus Torvalds <torvalds@transmeta.com> writes:

> Yeah, and the thing I think it _totally_ and utterly broken is that
> there can be only one of these per process.

> I don't see where the 1:1 idea comes from, except from a bad
> implementation.

If a single process is in possession of multiple sets of credentials at
the same time, how does the file system code in the kernel know which ones
to use for a given operation with a network file system?

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Linus Torvalds]

On 15 May 2003, Trond Myklebust wrote:
> 
> The interesting thing about a PAG is that it is a handle that is
> shared between userland and the kernel, and carries information about
> which collection of authentication tokens/credentials a process holds.

I agree. However, I think that the PAG namespace should be bigger than 
the uid namespace, so that you can have a mapping from uid to the PAG.

Also, I _know_ there are situations where you want to share credentials 
_without_ sharing "everything". That's why the unix notion of "group" 
exists, after all. And there is a good reason why people can be members of 
multiple groups at once.

The way the current PAG patch was set up, you could have only one PAG, and
the "join" operation worked on that single-pag level. Which means that if
you want to share credentials, you could do so at a key level (fair
enough), but the keys themselves were not shareable or joinable between
two PAG's.

> RPCSEC can be made to use it to communicate which bag of creds the
> userland daemon may use when it attempts to negotiate a new security
> context for an NFS user.

Absolutely. I just think it should be taken a step further.

Right now the limited PAG namespace as implemented by the current patch
means that a PAG ID number _has_ to be throw-away: the namespace is too
small to give users permanent PAG ID's. That's fine per se: you can always
create a mapping layer in some outside-of-the-kernel way (ie a database of
"user -> currently used PAG space"), but it's so much easier - I think -
to just make the name space big enough that you can have a trivial static
mapping "user -> permanent PAG ID".

So the PAG namespace thing is really just a detail, but one which I think
is indicative of how this thing would be used in practice.

The same thing to some degree goes for the "join" operation. Sure, you can
say that joining a PAG is unnecessary - you can always just create a new
one which has a copy of all the same keys. That's certainly true.

But especially if the keys are based off some private user knowledge (ie a
master session password required to initiate the first session), you most
likely _do_ want a "join" operation that is able to take advantage of the
fact that the user has already logged in once, and now just wants to
create a new session - without having to keep the password around on the
client.

So you want to be able to "join" a set of keys, but at the same that that
"join"  operation should not force you to use _only_ that set of keys. You
might have other keys that are truly private to just one process, ie you 
might want to have some "default level of single-sign-on" but then have an 
_additional_ "this set of keys requires me to use a one-time pad to 
access, and will not be shared with any other processes" kind of thing 
which is used for when you want to do something extra-sensitive.

In other words, I think of the credentials of equivalent to the private
keys that something like "ssh-agent" keeps around. But different 
connectors may want to have different disjoint sets of keys. Which is 
again why I think we want to have multiple PAG ID's per process.

And the reason I'd like to have the "uid -> default PAG" mapping is that
that one ends up being somewhat similar to the "SSH_AGENT_PID" environment
variable for that user. You can have multiple PAG's (or none), but I
envision one being set up for you by default. And you need _some_ key to
access that default PAG. And the obvious key to use is, to me, the already
existsing "uid".

Do I make sense?

		Linus

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Trond Myklebust]

>>>>> " " == Linus Torvalds <torvalds@transmeta.com> writes:

     > I'm interested in a much more generic issue of "user
     > credentials", and here a PAG can be _one_ credential that a
     > user holds on to. But to be useful, a user has to be able to
     > have multiple such credentials. While one might be his "AFS
     > userid", another will be his NFS mount credentials, and a third
     > one will be his key to decrypt his home directory on that
     > machine.

The interesting thing about a PAG is that it is a handle that is
shared between userland and the kernel, and carries information about
which collection of authentication tokens/credentials a process holds.

RPCSEC can be made to use it to communicate which bag of creds the
userland daemon may use when it attempts to negotiate a new security
context for an NFS user. At the moment all we can tell is 'use the
credentials of uid=zyx' which is no good if the user wants 2
subprocesses to authenticate using different remote kerberos accounts,
say.

Cheers,
  Trond

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Linus Torvalds]

On Wed, 14 May 2003, Garance A Drosihn wrote:
> 
>      For any process where pag != 0, that process will share
>      tokens with all other processes that have the exact same
>      pag value as it has.  This is true even if the different
>      processes are tied to different user ids.

Yeah, and the thing I think it _totally_ and utterly broken is that there 
can be only one of these per process.

I don't see where the 1:1 idea comes from, except from a bad 
implementation.

> There is absolutely no connection between userids and PAG's,
> the same way that there is no connection between userids and
> process-numbers.  (Roughly speaking:) The 10th person to log
> in will get the 10th pag, no matter what userid they happen
> to log in as.

And this is also again nothing but the result of a bad implementation.

>From a system maintenance issue, this is a nightmare. It makes joining a 
group nigh impossible, since now the joiner (login or something) has to 
keep track of what pag's it has used for previous logins. Which is fine as 
long as you have _one_ login authority, but it's a total disaster to 
require that kind of centralization.

> It's tokens which have some relation to userids.  In the world
> of AFS, a pag can hold only one token from any one AFS cell
> at a given time.  But I can change which "AFS userid" that I
> am, without changing which pag I am in, and all processes in
> that same pag will instantly become that same "AFS userid".

Yes. And apparently PAG's - as you see them - are nothing but a AFS issue.  
As such, I think they are totally uninteresting for the core kernel, and I
will _not_ be applying any patches that introduce such a limiting and
stupid notion into the core kernel.

I'm interested in a much more generic issue of "user credentials", and 
here a PAG can be _one_ credential that a user holds on to. But to be 
useful, a user has to be able to have multiple such credentials. While one 
might be his "AFS userid", another will be his NFS mount credentials, and 
a third one will be his key to decrypt his home directory on that machine.

If it's useful for AFS only, I'm not interested. 

		Linus

[OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Garance A Drosihn]

At 12:58 PM -0400 5/14/03, Jan Harkes wrote:
>On Wed, May 14, 2003, David Howells wrote:
>  > Here's a revised patch for adding PAG support that
>  > incorporates suggestions and corrections I've been sent.
>
>Please don't call this a pag. PAGs are defined as a simple
>unique integer session identifier [1]. Their main purpose it
>to provide a isolated permission environment, think of it as
>a chroot. So joining or leaving a PAG is just plain wrong.
>
>The implementation to add a PAG to Linux is really nothing
>more than adding single integer to the task and file structs.
>And a couple of functions to set a new unique value and query
>the value.
>
>AFS (and possibly DFS) style token management uses both the
>user id (fsuid?) and PAG id. It has simple rules,
>
>    All processes with (pag == 0 and same uid) share the
>        same tokens.
>    All processes with pag != 0 share the same tokens.

Let me rephrase this just a little bit, to make sure everyone
is getting the exactly same idea:

     For any process where pag != 0, that process will share
     tokens with all other processes that have the exact same
     pag value as it has.  This is true even if the different
     processes are tied to different user ids.

     Eg:  When doing 'sudo blah', the 'blah' process will
     still be in the exact same pag, and it will have all
     the exact same tokens, even though the process is
     running as uid root.  Another example would be setuid
     programs.

There is absolutely no connection between userids and PAG's,
the same way that there is no connection between userids and
process-numbers.  (Roughly speaking:) The 10th person to log
in will get the 10th pag, no matter what userid they happen
to log in as.

It's tokens which have some relation to userids.  In the world
of AFS, a pag can hold only one token from any one AFS cell
at a given time.  But I can change which "AFS userid" that I
am, without changing which pag I am in, and all processes in
that same pag will instantly become that same "AFS userid".

>This was my last mail on the subject as I seem the be the
>only one on that actually seem to view PAGs the way I do.

This would be a shame, as I think you've done a good job of
presenting a clear picture of what is really needed.

Disclaimer: I have no idea of what code changes would be
appropriate for the linux kernel, I'm just saying the above
description matches my idea of what a PAG should be.

-- 
Garance Alistair Drosehn            =   gad@gilead.netel.rpi.edu
Senior Systems Programmer           or  gad@freebsd.org
Rensselaer Polytechnic Institute    or  drosih@rpi.edu

Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2

[Harald Barth]

> This was my last mail on the subject as I seem the be the only one on
> that actually seem to view PAGs the way I do.

Jan, that would be a pity because in that case I (or someone else) of
the openafs-devel regulars would have to explain. I think you did a
better job that I would have done. You seem to have the references
handy. I can understand if you are not happy in writing more, because
part of the debate in this thread has been an all time low, rude and
very jumpy from one subject to another without getting anywhere. My
judgment is the one of a regular openafs-devel reader, customs in
other mailing lists may differ.

Asking questions is better that assuming something and waiting to be
proven wrong or right. Splitting up the problem in sub problems is
good, talking about function (the program mechanics) and form (coding
style) at the same time is difficult. Bad language is less convincing
than references.

A PAG is a session identifier (inherited like group membership) which
allows a user to temporarily switch to a new authentication context in
order to perform tasks which require this. The reference mentioned by
Jan explains this and I can add that I and a lot of fellow users use
it in that way on a daily basis. There are other related problems like
credential storage that need to be looked at, but that is not the same
thing as a PAG.

Harald.