LinuxLists.cc - [PATCH] PAG support, try #2

[permalink] [raw]

Subject: Re: [PATCH] PAG support, try #2

> These have to be a marked asmlinkage.

Damn. Fixed.

> What's the reason you have the syscall in this header anyway?

So they can be called from the AFS stub. However, the sys_*() versions
shouldn't be there.

> > +static kmem_cache_t *vfs_token_cache;
> > +static kmem_cache_t *vfs_pag_cache;
>
> So do you have an estimate for the number of users here yet?
> Adding two more slab caches that are unused for 99% of the users
> might not be the best choice if there's no strong need.

There won't be many PAGs. Basically one per login session would be fairly
typical, and possibly one per SUID program run at some later date.

> > +inline pag_t vfs_leave_pag(void)
>
> Inline but not static seems strange..

It's not without precedent within the kernel. The compiler is free to inline
it, but must also emit an out-of-line copy. Thinking about it, it's probably
not worth it... these calls aren't going to be called very often and so don't
need to be optimised for every last ounce of speed.

> We already discussed the coding style issue,

Well, the coding style is wrong here IMNSHO. Readability is preferable.

> but anyway, why aren't these three separate syscalls?

I'm trying not to cause hyper syscall breeding, but since they are three
separate logical functions, it I'll split it out anyway.

> What protects vfspag->tokens?

Why does it need to be protected at that point? The PAG no longer has any
references, and the tokens don't point back to it, and are in any case pinned
by virtue of being on the list.

> Please linwrap after 80 chars.

Done.

> Shouldn't vfs_pag_get hanlde a NULL argument instead?

Maybe. But then that's introducing a conditional branch that you can't avoid,
even if you know it's going to succeed:-/

> What happened to the suggestion to make the pag code optional? It's
> really easy to stub it out properly and most people don't need it.

Okay, I've conditionalised it.

David

2003-05-14 11:50:35

[permalink] [raw]

Subject: Re: [PATCH] PAG support, try #2

> > +typedef __kernel_pag_t pag_t;
>
> > +static pag_t vfs_pag_next = 1;
>
> > + vfspag->pag = vfs_pag_next++;
> > + if (vfspag->pag < 1)
> > + vfspag->pag = 1;
>
> Is there a reason pag_t isn't an unsigned int? Seems to me you'll have
> 2^31 good times followed by 2^31 bad times. Also, isn't signed overflow
> one of these undefined things? I wouldn't mention it except that gcc
> seem to be more and more fond of obeying the letter of the standard
> rather than doing useful stuff.

I made it the same as pid_t. However, -ve PIDs can have special meanings which
aren't applicable to PAGs, so I suppose it ought to be unsigned. Time to
change it again. Sigh.

David

2003-05-14 12:23:23

by Christoph Hellwig

[permalink] [raw]

Subject: Re: [PATCH] PAG support, try #2

On Wed, May 14, 2003 at 12:56:04PM +0100, David Howells wrote:
> > So do you have an estimate for the number of users here yet?
> > Adding two more slab caches that are unused for 99% of the users
> > might not be the best choice if there's no strong need.
>
> There won't be many PAGs. Basically one per login session would be fairly
> typical, and possibly one per SUID program run at some later date.

I think using plain kmalloc is better then.

> > Inline but not static seems strange..
>
> It's not without precedent within the kernel. The compiler is free to inline
> it, but must also emit an out-of-line copy. Thinking about it, it's probably
> not worth it... these calls aren't going to be called very often and so don't
> need to be optimised for every last ounce of speed.

Right, that's why I didn't complained very loud :)

> > We already discussed the coding style issue,
>
> Well, the coding style is wrong here IMNSHO. Readability is preferable.

No. Please follow the style guidelines. If you say readability is
preferable you habve to say whos. I always get stuck at code that
uses such strange constructs for example.

> > What protects vfspag->tokens?
>
> Why does it need to be protected at that point? The PAG no longer has any
> references, and the tokens don't point back to it, and are in any case pinned
> by virtue of being on the list.

Okay.

> > Shouldn't vfs_pag_get hanlde a NULL argument instead?
>
> Maybe. But then that's introducing a conditional branch that you can't avoid,
> even if you know it's going to succeed:-/

Then add an __vfs_pag_get that expects a non-NULL argument for those
cases where you know for sure it's not NULL.

2003-05-14 12:33:06

by William Lee Irwin III

[permalink] [raw]

Subject: Re: [PATCH] PAG support, try #2

On Wed, May 14, 2003 at 12:56:04PM +0100, David Howells wrote:
> There won't be many PAGs. Basically one per login session would be fairly
> typical, and possibly one per SUID program run at some later date.

That's very reassuring to me, thanks for clearing that up.

-- wli

2003-05-14 12:45:00

by Jeff Garzik

[permalink] [raw]

Subject: Re: [PATCH] PAG support, try #2

David Howells wrote:
>>We already discussed the coding style issue,
>
>
> Well, the coding style is wrong here IMNSHO. Readability is preferable.

Disagree -- using a non-standard style decreases readability simply
because it's non-standard.

One line of code, one test or operation. :)

Jeff

2003-05-14 16:37:41

[permalink] [raw]

Subject: Re: [PATCH] PAG support, try #2

On Wed, 14 May 2003, David Howells wrote:
>
> Here's a revised patch for adding PAG support that incorporates suggestions
> and corrections I've been sent.

I still really don't like this, and think it needs to be thought through a
_lot_ more. I also think this is _way_ waaaay too late to get into
2.6.x anyway.

Anyway, the thing I think is just fundamentally broken about this is

- I'm convinced this is designed for AFS, and not for any practical use.
For example, the "PAG" identifier (pag_t) is not any bigger than
"uid_t", which means that there is no sane way to map users onto pags
without just making them 1:1.

Which looks like a frigging _bad_ design, one that doesn't take account
of what a normal user (and current AFS/Kerberos users are by design
_not_ normal users) might want to have through something like "pam".

- A token can be on only one pag, which means that you have to duplicate
tokens and then have a very hard time revocing them if you want to. In
other words, you can never give another user (which by implication is
always another pag in my mind) a token, since you've now effectively
lost the ability to invalidate it (the other user gets a copy of the
token).

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.

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

Anyway, I htink the current patch is totally unusable for any reasonable
MIS setup (ie you couldn't make it useful as a PAM addition even if you
tried), and is totally special-cased for one (not very interesting, to me)
use.

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.

Linus

2003-05-14 16:45:59

by Jan Harkes

[permalink] [raw]

Subject: Re: [PATCH] PAG support, try #2

On Wed, May 14, 2003 at 11:43:31AM +0100, 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.

So this really works a lot like chroot. Normally everyone who logs in
inherits pag 0 from the init task and permissions will be shared based
on the userid. However if login newpags' us into a isolated environment
permissions are based on this session.

But the presented code seems to mix up sessions, tokens, lifetimes,
permissions. I cannot provide a isolated environment because people can
both join and leave an existing pag. The in-kernel token cache seems to
be more important, but things like tokens that expire and have to be
replaced while a file is already open are not dealt with.

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

[1] Integrating Security in a Large Distributed System (# 12)
Satyanarayanan, M.
ACM Transactions on Computer Systems
Aug. 1989, Vol. 7, No. 3, pp. 247-280
http://www-2.cs.cmu.edu/afs/cs/project/coda-www/ResearchWebPages/docdir/sec89.pdf

2003-05-14 16:59:15

by Jan Harkes

[permalink] [raw]

Subject: Re: [PATCH] PAG support, try #2

Ok I said that was my last mail, but I just noticed a really bad typo

On Wed, May 14, 2003 at 12:58:38PM -0400, Jan Harkes wrote:
> 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.
^^^^^^^^
the same non-zero pag

Jan

2003-05-14 17:24:29

[permalink] [raw]

Subject: Re: [PATCH] PAG support, try #2

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

2003-05-14 19:16:32

by H. Peter Anvin

[permalink] [raw]

Subject: Re: [PATCH] PAG support, try #2

Followup to: <[email protected]>
By author: Linus Torvalds <[email protected]>
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

--
<[email protected]> at work, <[email protected]> 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

2003-05-14 20:33:29

by Harald Barth

[permalink] [raw]

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

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

2003-05-15 00:02:26

[permalink] [raw]

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

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 = [email protected]
Senior Systems Programmer or [email protected]
Rensselaer Polytechnic Institute or [email protected]

2003-05-15 00:45:31

[permalink] [raw]

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

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

2003-05-15 01:21:55

by Trond Myklebust

[permalink] [raw]

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

>>>>> " " == Linus Torvalds <[email protected]> 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

2003-05-15 02:18:01

[permalink] [raw]

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

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

2003-05-15 04:13:42

by Russ Allbery

[permalink] [raw]

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

Linus Torvalds <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/>

2003-05-15 04:46:58

[permalink] [raw]

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

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

2003-05-15 13:00:04

[permalink] [raw]

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

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 = [email protected]
Senior Systems Programmer or [email protected]
Rensselaer Polytechnic Institute or [email protected]

2003-05-15 13:14:00

[permalink] [raw]

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

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 = [email protected]
Senior Systems Programmer or [email protected]
Rensselaer Polytechnic Institute or [email protected]

2003-05-15 13:22:51

[permalink] [raw]

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

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

2003-05-15 13:44:45

by chas williams

[permalink] [raw]

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

In message <[email protected]>,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.

2003-05-15 13:54:17

by Dean Anderson

[permalink] [raw]

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

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

2003-05-15 15:21:35

by Booker Bense

[permalink] [raw]

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

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

2003-05-15 15:43:07

by Douglas E. Engert

[permalink] [raw]

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

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 = [email protected]
> Senior Systems Programmer or [email protected]
> Rensselaer Polytechnic Institute or [email protected]
> _______________________________________________
> OpenAFS-devel mailing list
> [email protected]
> https://lists.openafs.org/mailman/listinfo/openafs-devel

--

Douglas E. Engert <[email protected]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444

2003-05-15 16:08:49

[permalink] [raw]

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

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

2003-05-15 16:28:44

[permalink] [raw]

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

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

2003-05-15 16:48:11

by Ingo Oeser

[permalink] [raw]

Subject: Re: [PATCH] PAG support, try #2

On Wed, May 14, 2003 at 06:37:00PM +0100, David Howells wrote:
> 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?

Union of both. And remember to subtract negative ACLs from
positive ACLs. Prioritize users over groups in case of explicit
mention.

This is standard permission checking.

Hmm, sounds too simple, so it must be wrong ;-)

Regards

Ingo Oeser

2003-05-15 17:11:53

[permalink] [raw]

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

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

2003-05-15 22:48:36

[permalink] [raw]

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

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 [email protected] and
[email protected] at the very same moment. It's just that I can not
be [email protected] and [email protected] (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 [email protected] -- and in fact I don't. There
is no "[email protected]", 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
[email protected]. I could just as well authenticate to userid
[email protected] (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 [email protected], but that does not mean
that anyone who knows the password to [email protected] 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 = [email protected]
Senior Systems Programmer or [email protected]
Rensselaer Polytechnic Institute or [email protected]

2003-05-15 23:09:46

by John Shillinglaw

[permalink] [raw]

Subject: QM_MODULES Function not implemented

This may be an part of a modules problem that's already fixed, but I
can't seem to fix it or find the answer, so if anyone can help and/or
point me to a resource to solve it, I ( and probably all the other RH
users) will be eternally grateful...

I'm running Red Hat 9 and have Rusty's Module init tools ( depmod V 9.12
pre1 ). I've read the posts about mkinitrd and have tried to make the
patches mentioned in the past about RH not handling *.ko modules.

I get the error message QM_MODULES: Function not implemented whenever
modprobe tries to load a module, ex. when loading usb or mouse, or
network...

What should I do to get 2.5.69 loading correctly? I know I could simply
figure out what I need and compile everything into the kernel. But I
would prefer to figure out what's wrong and correct it.

Thanks,
John
.config file follows:
#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=14

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_X86_PC=y
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
CONFIG_MPENTIUMII=y
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_SMP is not set
# CONFIG_PREEMPT is not set
# CONFIG_X86_UP_APIC is not set
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_EDD=m
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_SOFTWARE_SUSPEND is not set

#
# ACPI Support
#
# CONFIG_ACPI is not set
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
CONFIG_APM_RTC_IS_GMT=y
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_PCI_LEGACY_PROC is not set
CONFIG_PCI_NAMES=y
CONFIG_ISA=y
CONFIG_EISA=y
# CONFIG_EISA_VLB_PRIMING is not set
CONFIG_EISA_PCI_EISA=y
CONFIG_EISA_VIRTUAL_ROOT=y
CONFIG_EISA_NAMES=y
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=m
CONFIG_CARDBUS=y
CONFIG_I82092=m
CONFIG_I82365=m
CONFIG_TCIC=m
CONFIG_PCMCIA_PROBE=y

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
# CONFIG_PARPORT_SERIAL is not set
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
CONFIG_PARPORT_PC_PCMCIA=m
# CONFIG_PARPORT_OTHER is not set
CONFIG_PARPORT_1284=y

#
# Plug and Play support
#
CONFIG_PNP=y
CONFIG_PNP_NAMES=y
CONFIG_PNP_DEBUG=y

#
# Protocols
#
CONFIG_ISAPNP=y
# CONFIG_PNPBIOS is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
CONFIG_PARIDE=m
CONFIG_PARIDE_PARPORT=m

#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m

#
# Parallel IDE protocol modules
#
CONFIG_PARIDE_ATEN=m
CONFIG_PARIDE_BPCK=m
CONFIG_PARIDE_BPCK6=m
CONFIG_PARIDE_COMM=m
CONFIG_PARIDE_DSTR=m
CONFIG_PARIDE_FIT2=m
CONFIG_PARIDE_FIT3=m
CONFIG_PARIDE_EPAT=m
CONFIG_PARIDE_EPATC8=y
CONFIG_PARIDE_EPIA=m
CONFIG_PARIDE_FRIQ=m
CONFIG_PARIDE_FRPW=m
CONFIG_PARIDE_KBIC=m
CONFIG_PARIDE_KTTI=m
CONFIG_PARIDE_ON20=m
CONFIG_PARIDE_ON26=m
CONFIG_BLK_CPQ_DA=m
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_UMEM=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
# CONFIG_LBD is not set

#
# ATA/ATAPI/MFM/RLL device support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_IDEDISK_STROKE=y
CONFIG_BLK_DEV_IDECS=m
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDE_TCQ is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_BLK_DEV_ALI15X3=y
# CONFIG_WDC_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_TRIFLEX=y
CONFIG_BLK_DEV_CY82C693=y
# CONFIG_BLK_DEV_CS5520 is not set
CONFIG_BLK_DEV_HPT34X=y
CONFIG_BLK_DEV_HPT366=y
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_PDC202XX_OLD=y
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_PDC202XX_FORCE=y
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_SVWKS=y
CONFIG_BLK_DEV_SIIMAGE=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_SLC90E66=y
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_BLK_DEV_PDC202XX=y
CONFIG_BLK_DEV_IDE_MODES=y

#
# SCSI device support
#
CONFIG_SCSI=m

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_REPORT_LUNS=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
CONFIG_SCSI_AHA152X=m
CONFIG_SCSI_AHA1542=m
CONFIG_SCSI_AHA1740=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=253
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_PROBE_EISA_VL is not set
# CONFIG_AIC7XXX_BUILD_FIRMWARE is not set
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
CONFIG_SCSI_FUTURE_DOMAIN=m
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
CONFIG_SCSI_GENERIC_NCR5380_MMIO=m
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
# CONFIG_SCSI_IZIP_EPP16 is not set
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
# CONFIG_SCSI_NCR53C406A is not set
CONFIG_53C700_IO_MAPPED=y
# CONFIG_SCSI_NCR53C7xx is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_NCR53C8XX is not set
# CONFIG_SCSI_SYM53C8XX is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
CONFIG_SCSI_QLOGIC_FAS=m
CONFIG_SCSI_QLOGIC_ISP=m
CONFIG_SCSI_QLOGIC_FC=m
# CONFIG_SCSI_QLOGIC_FC_FIRMWARE is not set
CONFIG_SCSI_QLOGIC_1280=m
CONFIG_SCSI_SEAGATE=m
CONFIG_SCSI_SIM710=m
CONFIG_SCSI_SYM53C416=m
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
CONFIG_SCSI_U14_34F=m
# CONFIG_SCSI_U14_34F_TAGGED_QUEUE is not set
# CONFIG_SCSI_U14_34F_LINKED_COMMANDS is not set
CONFIG_SCSI_U14_34F_MAX_TAGS=8
CONFIG_SCSI_ULTRASTOR=m
CONFIG_SCSI_NSP32=m
CONFIG_SCSI_DEBUG=m

#
# PCMCIA SCSI adapter support
#
CONFIG_PCMCIA_AHA152X=m
CONFIG_PCMCIA_FDOMAIN=m
CONFIG_PCMCIA_NINJA_SCSI=m
CONFIG_PCMCIA_QLOGIC=m

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#
CONFIG_FUSION=m
CONFIG_FUSION_MAX_SGE=40
# CONFIG_FUSION_ISENSE is not set
CONFIG_FUSION_CTL=m

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
CONFIG_IEEE1394=m

#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
# CONFIG_IEEE1394_OUI_DB is not set

#
# Device Drivers
#
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_OHCI1394=m

#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
CONFIG_IEEE1394_SBP2_PHYS_DMA=y
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
CONFIG_IEEE1394_CMP=m
CONFIG_IEEE1394_AMDTP=m

#
# I2O device support
#
CONFIG_I2O=m
CONFIG_I2O_PCI=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_NAT=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_TOS=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_ROUTE_LARGE_TABLES=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
CONFIG_IP_NF_IRC=m
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_UNCLEAN=m
CONFIG_IP_NF_MATCH_OWNER=m
# CONFIG_IP_NF_MATCH_PHYSDEV is not set
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_MIRROR=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
# CONFIG_IP_NF_NAT_LOCAL is not set
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_COMPAT_IPCHAINS=m
CONFIG_IP_NF_COMPAT_IPFWADM=m
CONFIG_IPV6=m
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set

#
# IPv6: Netfilter Configuration
#
# CONFIG_IP6_NF_QUEUE is not set
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
# CONFIG_IP6_NF_MATCH_RT is not set
# CONFIG_IP6_NF_MATCH_OPTS is not set
# CONFIG_IP6_NF_MATCH_FRAG is not set
# CONFIG_IP6_NF_MATCH_HL is not set
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
# CONFIG_IP6_NF_MATCH_IPV6HEADER is not set
# CONFIG_IP6_NF_MATCH_AHESP is not set
CONFIG_IP6_NF_MATCH_LENGTH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m
# CONFIG_XFRM_USER is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=m
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
CONFIG_VLAN_8021Q=m
# CONFIG_LLC is not set
# CONFIG_DECNET is not set
CONFIG_BRIDGE=m
# CONFIG_BRIDGE_NF_EBTABLES is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
CONFIG_NET_DIVERT=y
# CONFIG_ECONET is not set
CONFIG_WAN_ROUTER=m
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_CSZ=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_POLICE=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_ETHERTAP=m
CONFIG_NET_SB1000=m

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_MII is not set
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_NET_VENDOR_3COM=y
CONFIG_EL1=m
CONFIG_EL2=m
CONFIG_ELPLUS=m
CONFIG_EL16=m
CONFIG_EL3=m
CONFIG_3C515=m
CONFIG_VORTEX=m
# CONFIG_TYPHOON is not set
CONFIG_LANCE=m
CONFIG_NET_VENDOR_SMC=y
CONFIG_WD80x3=m
CONFIG_ULTRA=m
CONFIG_ULTRA32=m
CONFIG_SMC9194=m
CONFIG_NET_VENDOR_RACAL=y
CONFIG_NI5010=m
CONFIG_NI52=m
CONFIG_NI65=m

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
CONFIG_AT1700=m
CONFIG_DEPCA=m
CONFIG_HP100=m
CONFIG_NET_ISA=y
CONFIG_E2100=m
CONFIG_EWRK3=m
CONFIG_EEXPRESS=m
CONFIG_EEXPRESS_PRO=m
CONFIG_HPLAN_PLUS=m
CONFIG_HPLAN=m
CONFIG_LP486E=m
CONFIG_ETH16I=m
CONFIG_NE2000=m
# CONFIG_ZNET is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_AMD8111_ETH=m
CONFIG_ADAPTEC_STARFIRE=m
# CONFIG_ADAPTEC_STARFIRE_NAPI is not set
CONFIG_AC3200=m
CONFIG_APRICOT=m
# CONFIG_B44 is not set
CONFIG_CS89x0=m
CONFIG_DGRS=m
CONFIG_EEPRO100=m
# CONFIG_EEPRO100_PIO is not set
CONFIG_E100=m
CONFIG_LNE390=m
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_NE3210=m
CONFIG_ES3210=m
CONFIG_8139CP=m
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_SIS900=m
CONFIG_EPIC100=m
CONFIG_SUNDANCE=m
CONFIG_SUNDANCE_MMIO=y
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
# CONFIG_VIA_RHINE_MMIO is not set
CONFIG_NET_POCKET=y
CONFIG_ATP=m
CONFIG_DE600=m
CONFIG_DE620=m

#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_DL2K=m
CONFIG_E1000=m
# CONFIG_E1000_NAPI is not set
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
CONFIG_R8169=m
CONFIG_SK98LIN=m
CONFIG_TIGON3=m

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
# CONFIG_PPP_BSDCOMP is not set
# CONFIG_PPPOE is not set
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y

#
# Obsolete Wireless cards support (pre-802.11)
#
CONFIG_STRIP=m
CONFIG_ARLAN=m
CONFIG_WAVELAN=m
CONFIG_PCMCIA_WAVELAN=m
CONFIG_PCMCIA_NETWAVE=m

#
# Wireless 802.11 Frequency Hopping cards support
#
CONFIG_PCMCIA_RAYCS=m

#
# Wireless 802.11b ISA/PCI cards support
#
CONFIG_AIRO=m
CONFIG_HERMES=m
CONFIG_PLX_HERMES=m
CONFIG_PCI_HERMES=m

#
# Wireless 802.11b Pcmcia/Cardbus cards support
#
CONFIG_PCMCIA_HERMES=m
CONFIG_AIRO_CS=m
CONFIG_NET_WIRELESS=y

#
# Token Ring devices (depends on LLC=y)
#
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# PCMCIA network device support
#
CONFIG_NET_PCMCIA=y
CONFIG_PCMCIA_3C589=m
CONFIG_PCMCIA_3C574=m
CONFIG_PCMCIA_FMVJ18X=m
CONFIG_PCMCIA_PCNET=m
CONFIG_PCMCIA_NMCLAN=m
CONFIG_PCMCIA_SMC91C92=m
CONFIG_PCMCIA_XIRC2PS=m
CONFIG_PCMCIA_AXNET=m

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
CONFIG_IRDA=m

#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
CONFIG_IRDA_ULTRA=y

#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
# CONFIG_IRDA_DEBUG is not set

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m

#
# Dongle support
#
CONFIG_DONGLE=y
CONFIG_ESI_DONGLE=m
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m

#
# Old SIR device drivers
#
# CONFIG_IRTTY_OLD is not set
CONFIG_IRPORT_SIR=m

#
# Old Serial dongle support
#
# CONFIG_DONGLE_OLD is not set

#
# FIR device drivers
#
CONFIG_USB_IRDA=m
CONFIG_NSC_FIR=m
CONFIG_WINBOND_FIR=m
CONFIG_TOSHIBA_OLD=m
CONFIG_TOSHIBA_FIR=m
CONFIG_SMC_IRCC_FIR=m
CONFIG_ALI_FIR=m
CONFIG_VLSI_FIR=m

#
# ISDN subsystem
#
# CONFIG_ISDN_BOOL is not set

#
# Telephony Support
#
CONFIG_PHONE=m
CONFIG_PHONE_IXJ=m
CONFIG_PHONE_IXJ_PCMCIA=m

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_DIGI is not set
# CONFIG_ESPSERIAL is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
CONFIG_N_HDLC=m
# CONFIG_RISCOM8 is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
# CONFIG_SERIAL_8250_CS is not set
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=2048
CONFIG_PRINTER=m
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=m
CONFIG_TIPAR=m

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_PHILIPSPAR=m
CONFIG_I2C_ELV=m
CONFIG_I2C_VELLEMAN=m
# CONFIG_SCx200_ACB is not set
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ELEKTOR=m
CONFIG_I2C_CHARDEV=m

#
# I2C Hardware Sensors Mainboard support
#
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_ISA is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_VIAPRO is not set

#
# I2C Hardware Sensors Chip support
#
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_I2C_SENSOR is not set

#
# Mice
#
CONFIG_BUSMOUSE=m
# CONFIG_QIC02_TAPE is not set

#
# IPMI
#
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_KCS=m
CONFIG_IPMI_WATCHDOG=m

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
CONFIG_SOFT_WATCHDOG=m
CONFIG_WDT=m
CONFIG_WDTPCI=m
# CONFIG_WDT_501 is not set
CONFIG_PCWATCHDOG=m
CONFIG_ACQUIRE_WDT=m
CONFIG_ADVANTECH_WDT=m
CONFIG_EUROTECH_WDT=m
CONFIG_IB700_WDT=m
CONFIG_I810_TCO=m
# CONFIG_MIXCOMWD is not set
# CONFIG_SCx200_WDT is not set
# CONFIG_60XX_WDT is not set
CONFIG_W83877F_WDT=m
CONFIG_MACHZ_WDT=m
CONFIG_SC520_WDT=m
CONFIG_AMD7XX_TCO=m
CONFIG_ALIM7101_WDT=m
CONFIG_SC1200_WDT=m
CONFIG_WAFER_WDT=m
# CONFIG_CPU5_WDT is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=m
CONFIG_RTC=y
CONFIG_DTLK=m
CONFIG_R3964=m
# CONFIG_APPLICOM is not set
CONFIG_SONYPI=m

#
# Ftape, the floppy tape device driver
#
CONFIG_FTAPE=m
CONFIG_ZFTAPE=m
CONFIG_ZFT_DFLT_BLK_SZ=10240

#
# The compressor will be built as a module only!
#
CONFIG_ZFT_COMPRESSOR=m
CONFIG_FT_NR_BUFFERS=3
# CONFIG_FT_PROC_FS is not set
CONFIG_FT_NORMAL_DEBUG=y
# CONFIG_FT_FULL_DEBUG is not set
# CONFIG_FT_NO_TRACE is not set
# CONFIG_FT_NO_TRACE_AT_ALL is not set

#
# Hardware configuration
#
CONFIG_FT_STD_FDC=y
# CONFIG_FT_MACH2 is not set
# CONFIG_FT_PROBE_FC10 is not set
# CONFIG_FT_ALT_FDC is not set
CONFIG_FT_FDC_THR=8
CONFIG_FT_FDC_MAX_RATE=2000
CONFIG_FT_ALPHA_CLOCK=0
CONFIG_AGP=m
CONFIG_AGP_INTEL=m
CONFIG_AGP_VIA=m
CONFIG_AGP_AMD=m
CONFIG_AGP_SIS=m
CONFIG_AGP_ALI=m
CONFIG_AGP_SWORKS=m
CONFIG_AGP_AMD_8151=m
CONFIG_DRM=y
CONFIG_DRM_TDFX=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_MGA=m

#
# PCMCIA character devices
#
CONFIG_SYNCLINK_CS=m
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#
CONFIG_VIDEO_PROC_FS=y

#
# Video Adapters
#
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_PMS=m
CONFIG_VIDEO_BWQCAM=m
CONFIG_VIDEO_CQCAM=m
CONFIG_VIDEO_W9966=m
CONFIG_VIDEO_CPIA=m
CONFIG_VIDEO_CPIA_PP=m
CONFIG_VIDEO_CPIA_USB=m
CONFIG_VIDEO_SAA5249=m
CONFIG_TUNER_3036=m
CONFIG_VIDEO_STRADIS=m
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_ZR36120 is not set
# CONFIG_VIDEO_MEYE is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set

#
# Radio Adapters
#
CONFIG_RADIO_CADET=m
CONFIG_RADIO_RTRACK=m
CONFIG_RADIO_RTRACK2=m
CONFIG_RADIO_AZTECH=m
CONFIG_RADIO_GEMTEK=m
CONFIG_RADIO_GEMTEK_PCI=m
CONFIG_RADIO_MAXIRADIO=m
CONFIG_RADIO_MAESTRO=m
CONFIG_RADIO_SF16FMI=m
CONFIG_RADIO_TERRATEC=m
CONFIG_RADIO_TRUST=m
CONFIG_RADIO_TYPHOON=m
CONFIG_RADIO_TYPHOON_PROC_FS=y
CONFIG_RADIO_ZOLTRIX=m

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
CONFIG_VIDEO_VIDEOBUF=m
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_BUF=m
CONFIG_VIDEO_BTCX=m

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
# CONFIG_EXT3_FS_POSIX_ACL is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
CONFIG_JFS_FS=m
# CONFIG_JFS_POSIX_ACL is not set
CONFIG_JFS_DEBUG=y
# CONFIG_JFS_STATISTICS is not set
# CONFIG_XFS_FS is not set
CONFIG_MINIX_FS=m
CONFIG_ROMFS_FS=m
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=m

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
CONFIG_HFS_FS=m
CONFIG_BEFS_FS=m
# CONFIG_BEFS_DEBUG is not set
CONFIG_BFS_FS=m
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=m
CONFIG_VXFS_FS=m
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set

#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_NFS_V4 is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V4 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_SUNRPC=m
# CONFIG_SUNRPC_GSS is not set
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
# CONFIG_CIFS is not set
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_CODA_FS=m
# CONFIG_INTERMEZZO_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
CONFIG_LDM_PARTITION=y
# CONFIG_LDM_DEBUG is not set
# CONFIG_NEC98_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
CONFIG_SMB_NLS=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m

#
# Graphics support
#
CONFIG_FB=y
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=y
CONFIG_FB_VESA=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB_HGA=m
CONFIG_FB_RIVA=m
# CONFIG_FB_I810 is not set
# CONFIG_FB_MATROX is not set
CONFIG_FB_RADEON=m
CONFIG_FB_ATY128=m
CONFIG_FB_ATY=m
CONFIG_FB_ATY_CT=y
CONFIG_FB_ATY_GX=y
# CONFIG_FB_ATY_XL_INIT is not set
CONFIG_FB_SIS=m
CONFIG_FB_SIS_300=y
CONFIG_FB_SIS_315=y
CONFIG_FB_NEOMAGIC=m
CONFIG_FB_3DFX=m
CONFIG_FB_VOODOO1=m
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE is not set

#
# Logo configuration
#
# CONFIG_LOGO is not set

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_SEQUENCER=m
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_VERBOSE_PRINTK=y
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
CONFIG_SND_MPU401=m

#
# ISA devices
#
CONFIG_SND_AD1816A=m
CONFIG_SND_AD1848=m
CONFIG_SND_CS4231=m
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
CONFIG_SND_ES968=m
CONFIG_SND_ES1688=m
CONFIG_SND_ES18XX=m
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
CONFIG_SND_OPTI92X_AD1848=m
CONFIG_SND_OPTI92X_CS4231=m
CONFIG_SND_OPTI93X=m
# CONFIG_SND_SB8 is not set
CONFIG_SND_SB16=m
CONFIG_SND_SBAWE=m
CONFIG_SND_SB16_CSP=y
# CONFIG_SND_WAVEFRONT is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
CONFIG_SND_CMI8330=m
# CONFIG_SND_DT019X is not set
CONFIG_SND_OPL3SA2=m
# CONFIG_SND_SGALAXY is not set

#
# PCI devices
#
CONFIG_SND_ALI5451=m
CONFIG_SND_CS46XX=m
# CONFIG_SND_CS46XX_NEW_DSP is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_ALS4000 is not set
CONFIG_SND_CMIPCI=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
CONFIG_SND_ES1938=m
CONFIG_SND_ES1968=m
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_SONICVIBES is not set
CONFIG_SND_VIA82XX=m

#
# ALSA USB devices
#
CONFIG_SND_USB_AUDIO=m

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB=m
CONFIG_USB_DEBUG=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_UHCI_HCD=m

#
# USB Device Class drivers
#
CONFIG_USB_AUDIO=m
# CONFIG_USB_BLUETOOTH_TTY is not set
CONFIG_USB_MIDI=m
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_HP8200e=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y

#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=m
# CONFIG_USB_HIDINPUT is not set
# CONFIG_USB_HIDDEV is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
CONFIG_USB_AIPTEK=m
CONFIG_USB_WACOM=m
# CONFIG_USB_KBTAB is not set
CONFIG_USB_POWERMATE=m
# CONFIG_USB_XPAD is not set

#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_SCANNER=m
CONFIG_USB_MICROTEK=m
CONFIG_USB_HPUSBSCSI=m

#
# USB Multimedia devices
#
CONFIG_USB_DABUSB=m
CONFIG_USB_VICAM=m
CONFIG_USB_DSBR=m
CONFIG_USB_IBMCAM=m
# CONFIG_USB_KONICAWC is not set
CONFIG_USB_OV511=m
CONFIG_USB_PWC=m
CONFIG_USB_SE401=m
CONFIG_USB_STV680=m

#
# USB Network adaptors
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=m

#
# USB Host-to-Host Cables
#
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_GENESYS=y
CONFIG_USB_NET1080=y
CONFIG_USB_PL2301=y

#
# Intelligent USB Devices/Gadgets
#
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_ZAURUS=y
CONFIG_USB_CDCETHER=y

#
# USB port drivers
#
CONFIG_USB_USS720=m

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
# CONFIG_USB_SERIAL_KEYSPAN_MPR is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
# CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set
CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y
# CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA49WLC is not set
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_PL2303=m
# CONFIG_USB_SERIAL_SAFE is not set
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_EZUSB=y

#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI26=m
CONFIG_USB_TIGL=m
CONFIG_USB_AUERSWALD=m
CONFIG_USB_RIO500=m
CONFIG_USB_BRLVGER=m
CONFIG_USB_LCD=m
# CONFIG_USB_TEST is not set

#
# Bluetooth support
#
# CONFIG_BT is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_KALLSYMS is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_FRAME_POINTER is not set

#
# Security options
#
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Library routines
#
# CONFIG_CRC32 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_X86_BIOS_REBOOT=y

2003-05-15 23:33:24

by Peter Chubb

[permalink] [raw]

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

>>>>> "chas" == chas williams <[email protected]> writes:

chas> In message <[email protected]>,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.

2003-05-16 00:40:59

by Nathan Neulinger

[permalink] [raw]

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

> 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: [email protected]
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216

2003-05-16 12:00:56