[lkml]   [2003]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] in-core AFS multiplexor and PAG support
On Tue, May 13, 2003 at 09:47:59AM -0700, Linus Torvalds wrote:
> > Maybe... There are arguments either way, but if the token ring is kept in
> > struct user, a task can't detach from it and pass a token-less set of keys
> > onto another process it wants to run.
> Oh, but it can. The pointer should be kept at two places: the "struct
> task_struct" contains the initial pre-process value, and at file open time
> that pointer should get copied (and the user count incremented) and put
> into the "struct file".
> So you can pass the set of keys the way UNIX _always_ passes rights -
> through the file descriptor.

Right, if some process/user opens a file and then passes the descriptor
to another process/user which closes it. The close should operate under
the same permissions as the original opener.

Simple example when this happens is when a setuid application is started
and the stdout/stderr is redirected to a file. 'ping foo >out 2>&1'. The
shell opens the file under my uid, but the setuid application closes it
under the new uid.

> The advantage of associating the PAG with the real uid rather than make it
> per-process is that it's a lot easier to administer that way, I think. You
> don't need to log out or anything like that to have changes take effect
> for your session, and it is very natural to say "this user now gets key
> X". Which is what I think you really want when you do something like enter
> a key to an encrypted filesystem, for example.

The local user id is not a 'trusted' identity for a distributed filesystem.
Any user still have to prove his identity by obtaining tokens.

If someone obtains my user id on in any way (i.e. weak password/
bufferoverflow/ root exploit), he should not be allowed to use or access
my tokens as he hasn't proven his identity. In this case he would either
still be in his original process authentication group, or a new and
empty PAG. But definitely not in any of my authentication groups.

Which is also why joining a PAG should never be allowed.

Any arguments about 'it avoids the cost of obtaining credentials' are
stupid because that cost is exactly what it takes to prove that a new
session is in fact associated with a specific user. If our identity
already was proven beyond reasonable doubt, we clearly already have our
'token' and the additional cost to associate this with the new PAG is


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:35    [W:0.104 / U:2.052 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site