lkml.org 
[lkml]   [2003]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] PAG support, try #2
Date
From

Hmmm... you aren't really taking about PAGs anymore, but no matter...

> End result: again, this looks like it is designed for the _wrong_ usage
> of sharing a whole PAG or sharing nothing at all. Which is probably
> what current AFS users do, but it sounds inflexible and _wrong_ to me.
> The main PAG usage I personally envision would be something where the
> PAG contains the decryption key to a filesystem or similar, which
> definitely is something where you (a) want to have multiple keys and
> (b) you want to have multiple PAG's that can share some keys without
> being the same PAG.

It looks like what you want is for there to be a user_struct and a
group_struct, each with a list of tokens.

A process would then have the set conjuction of the sets of tokens
corresponding to its EUID, EGID and GROUPS.

> I suspect both of these problems could be fixed by another level of
> indirection: a "user credential" is really a "list of PAG's", with the PAG
> being a "list of keys". Joining a PAG _adds_ that PAG to the user
> credentials, instead of replacing the old credentials with the new one.

And you'd need to be able to do a "subset" operation too (ultimately producing
an empty set), if only to run another program with reduced authority.

> - 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.

That makes the situation more complicated, because you wouldn't necessarily
want all processes owned by a user to gain (even temporarily) a token loaned
from one process to another.

> 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).

And then you have to have some method of prioritisation. You may find that
user dhowells has a token for (fs=AFS,cell=redhat.com) and group engineering
has a token for (fs=AFS,cell=redhat.com). Which do you use?

> Anyway, I htink the current patch is totally unusable for any reasonable
> MIS setup

What's "MIS"?

> (ie you couldn't make it useful as a PAM addition even if you tried),

OpenAFS does make it a useful and automatic PAM addition.

> and is totally special-cased for one (not very interesting, to me) use.

It can be used for other filesystems.

> And I think this will be a 2.7.x issue, if only because you guys will need
> to convince me that I'm wrong.

Fair enough. I'm unlikely to get security added to my AFS client before the
2.6 freeze.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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