My idea was to add a separate daemon that is called somehow and told
the username/password and processid and the server will then change
the uid of the calling process after verifying the username/password.
>From a security point of view I think I've solved the problem, but I've
got some problems with the implementation.
The only way I've come up with regarding sending the pid securely from
one process to another is via a unix domain socket, a lookup in
/proc/net/unix to find the address of the socket, some reading of
/dev/kmem to find the other end of the connected socket, from there
the inode number of the socket and then comparing that to
/proc/PID/fd/fdnumber's link information. I think I've managed to get
that working without any race conditions.
That is perhapps an acceptable solution even though I don't like messing
with /dev/kmem.
The next problem is to change the uid of the other process. Again, this
is a job for /dev/kmem. But here comes the problem. Since the task
structure is stored in a linked list, is it possible to find the other
process' task structure without having to gamble with raceconditions from
a nonkernel process?
A better solution is perhapps to extend the unix domain sockets instead,
so they can transfer uids/gids just like they can transfer
filedescriptors? Is this something that could be added to the standard
kernel if it was implemented?
/Sebastian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu