PAG support, try #2

Hi Linus,

Here's a revised patch for adding PAG support that incorporates suggestions and corrections I've been sent.

David

diff -uNr linux-2.5.69/arch/i386/kernel/entry.S linux-2.5.69-pag/arch/i386/kernel/entry.S
@@ -852,6 +852,7 @@
  	.long sys_clock_gettime		/* 265 */
  	.long sys_clock_getres
  	.long sys_clock_nanosleep
- 
+	.long sys_setpag
+	.long sys_getpag
  
 nr_syscalls=(.-sys_call_table)/4

diff -uNr linux-2.5.69/fs/file_table.c linux-2.5.69-pag/fs/file_table.c
@@ -166,6 +166,7 @@
 	if (file->f_op && file->f_op->release)
 		file->f_op->release(inode, file);
 	security_file_free(file);
+	vfs_token_put(file->f_token);
 	fops_put(file->f_op);
 	if (file->f_mode & FMODE_WRITE)
 		put_write_access(inode);

diff -uNr linux-2.5.69/fs/proc/array.c linux-2.5.69-pag/fs/proc/array.c
@@ -154,13 +154,14 @@
 	read_lock(&tasklist_lock);
 	buffer += sprintf(buffer,
 		"State:\t%s\n"
+		"Pag:\t%d\n"
 		"Tgid:\t%d\n"
 		"Pid:\t%d\n"
 		"PPid:\t%d\n"
 		"TracerPid:\t%d\n"
 		"Uid:\t%d\t%d\t%d\t%d\n"
 		"Gid:\t%d\t%d\t%d\t%d\n",
-		get_task_state(p), p->tgid,
+		get_task_state(p), p->vfspag ? p->vfspag->pag : 0, p->tgid,
 		p->pid, p->pid ? p->real_parent->pid : 0,
 		p->pid && p->ptrace ? p->parent->pid : 0,
 		p->uid, p->euid, p->suid, p->fsuid,

diff -uNr linux-2.5.69/include/asm-i386/posix_types.h linux-2.5.69-pag/include/asm-i386/posix_types.h
@@ -13,6 +13,7 @@
 typedef unsigned short	__kernel_nlink_t;
 typedef long		__kernel_off_t;
 typedef int		__kernel_pid_t;
+typedef int		__kernel_pag_t;
 typedef unsigned short	__kernel_ipc_pid_t;
 typedef unsigned short	__kernel_uid_t;
 typedef unsigned short	__kernel_gid_t;

diff -uNr linux-2.5.69/include/asm-i386/unistd.h linux-2.5.69-pag/include/asm-i386/unistd.h
@@ -273,8 +273,10 @@
 #define __NR_clock_gettime	(__NR_timer_create+6)
 #define __NR_clock_getres	(__NR_timer_create+7)
 #define __NR_clock_nanosleep	(__NR_timer_create+8)
+#define __NR_setpag		268
+#define __NR_getpag		269
 
-#define NR_syscalls 268
+#define NR_syscalls 270
 
 /* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
 

diff -uNr linux-2.5.69/include/linux/fs.h linux-2.5.69-pag/include/linux/fs.h
@@ -430,6 +430,7 @@
 	mode_t			f_mode;
 	loff_t			f_pos;
 	struct fown_struct	f_owner;
+	struct vfs_token	*f_token;	/* governing credential */
 	unsigned int		f_uid, f_gid;
 	int			f_error;
 	struct file_ra_state	f_ra;

diff -uNr linux-2.5.69/include/linux/sched.h linux-2.5.69-pag/include/linux/sched.h
@@ -28,6 +28,7 @@
 #include <linux/completion.h>
 #include <linux/pid.h>
 #include <linux/percpu.h>
+#include <linux/cred.h>
 
 struct exec_domain;
 

@@ -387,6 +388,7 @@
 	gid_t gid,egid,sgid,fsgid;
 	int ngroups;
 	gid_t	groups[NGROUPS];
+	struct vfs_pag *vfspag;
 	kernel_cap_t   cap_effective, cap_inheritable, cap_permitted;
 	int keep_capabilities:1;
 	struct user_struct *user;

diff -uNr linux-2.5.69/include/linux/types.h linux-2.5.69-pag/include/linux/types.h
@@ -24,6 +24,7 @@
 typedef __kernel_nlink_t	nlink_t;
 typedef __kernel_off_t		off_t;
 typedef __kernel_pid_t		pid_t;
+typedef __kernel_pag_t		pag_t;
 typedef __kernel_daddr_t	daddr_t;
 typedef __kernel_key_t		key_t;
 typedef __kernel_suseconds_t	suseconds_t;

diff -uNr linux-2.5.69/init/main.c linux-2.5.69-pag/init/main.c
@@ -80,6 +80,7 @@
 extern void pidhash_init(void);
 extern void pidmap_init(void);
 extern void pte_chain_init(void);
+extern void credentials_init(void);
 extern void radix_tree_init(void);
 extern void free_initmem(void);
 extern void populate_rootfs(void);

@@ -434,6 +435,7 @@
 	pidmap_init();
 	pgtable_cache_init();
 	pte_chain_init();
+	credentials_init();
 	fork_init(num_physpages);
 	proc_caches_init();
 	security_scaffolding_startup();

diff -uNr linux-2.5.69/kernel/fork.c linux-2.5.69-pag/kernel/fork.c
@@ -884,6 +884,10 @@
 
 	if (clone_flags & CLONE_CHILD_SETTID)
 		p->set_child_tid = child_tidptr;
+
+	if (p->vfspag)
+		vfs_pag_get(p->vfspag);
+
 	/*
 	 * Clear TID on mm_release()?
 	 */

diff -uNr linux-2.5.69/kernel/Makefile linux-2.5.69-pag/kernel/Makefile
@@ -3,7 +3,7 @@
 #
 
 obj-y     = sched.o fork.o exec_domain.o panic.o printk.o profile.o \
-	    exit.o itimer.o time.o softirq.o resource.o \
+	    cred.o exit.o itimer.o time.o softirq.o resource.o \
 	    sysctl.o capability.o ptrace.o timer.o user.o \
 	    signal.o sys.o kmod.o workqueue.o futex.o pid.o \
 	    rcupdate.o intermodule.o extable.o params.o posix-timers.o

Inline but not static seems strange..

Please linwrap after 80 chars.

Damn. Fixed.

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

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.

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.

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

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

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.

Done.

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

Okay, I've conditionalised it.

David

I think using plain kmalloc is better then.

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

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.

Okay.

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

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

-- wli

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

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

Jeff

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

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

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

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.

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.

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.

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?

What's "MIS"?

OpenAFS does make it a useful and automatic PAM addition.

It can be used for other filesystems.

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

David

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

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

Quite. Now that you've done the math, please explain how this should be implemented efficiently. These are *networked* filesystems...

Cheers,
Trond

Followup to:  <[email protected]>
By author:    Linus Torvalds <[email protected]>
In newsgroup: linux.dev.kernel

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

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

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

		        ^^^^^^^^
		     the same non-zero pag

Jan

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.

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

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.

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

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.

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

> 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

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.

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

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

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.

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

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.

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

PAG IDs _are_ ephemeral.

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

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.

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

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

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

David

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

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

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

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

I concur.

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

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

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

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

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

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

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

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

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

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

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

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

(*) list-sessions <name>

List keyrings available to this process

(*) list-keys <name>

List keys in the available session

(*) upgrade-session <name>

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

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

Add a key to the primary or named session.

David

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

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!

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.

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.

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.

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.

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.

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]

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

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

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)

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

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

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

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

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

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

- 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

Hi Russ.

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

Best wishes from Riley.
---
* Nothing as pretty as a smile, nothing as ugly as a frown.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.481 / Virus Database: 277 - Release Date: 13-May-2003

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

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?

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.

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

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]

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.

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

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.

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

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.

PAG IDs are designed to be throw-away.

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

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.