On Monday, July 17, 2006 06:15:21 PM -0400 chas williams - CONTRACTOR
<[EMAIL PROTECTED]> wrote:
In message <[EMAIL PROTECTED]>,Jeffrey
Hutzelman w rites:
This is fine as a proof-of-concept, but for something real the existing
setpag() and pioctl() system calls need to continue to work. There are
things that use these interfaces other than our own library, and IMHO it
is
setpag() still works the same, but does require another library to
be linked against it. yes, this is a drag.
I guess I was unclear. I don't mean setpag() the library call, I mean
AFSCALL_SETPAG, as called via afs_syscall() or the /proc ioctl interface.
OpenAFS's libsys.a is not the only thing that knows how to use this
interface, and it's not reasonable to make other things that use it stop
working, especially if the failure mode is that they think everything is
fine except it didn't do anything.
I haven't looked at what you did in detail, but it sounds like part of
setpag() in your model is setting a key from usermode which contains the
PAG ID. I'm not sure where you get the ID or what restrictions are
enforced, but obviously a user process must not be able to set any
arbitrary PAG ID it wants.
i didnt run into this, because i built a new login.krb5 which calls
setpag(). so my key is owned by root and i am unable to modify
it:
Sure, but what happens to a process that creates a new session keyring, and
thus has no PAG? Can't it then join any PAG it wants?
so the PagInCred() could trust only key's owned by root.
I suppose you could do this, except that then you have to be root to call
setpag().
Please try to make the existing interfaces work, rather than just the
programs we happen to ship that use those interfaces.
-- Jeff
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
