Date: Wed, 15 Nov 2000 08:47:22 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Peter Pentchev <roam@orbitel.bg> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: changing a running process's credentials Message-ID: <20001115084722.I29448@fw.wintelcom.net> In-Reply-To: <20001115161316.C309@ringworld.oblivion.bg>; from roam@orbitel.bg on Wed, Nov 15, 2000 at 04:13:16PM %2B0200 References: <20001115161316.C309@ringworld.oblivion.bg>
next in thread | previous in thread | raw e-mail | index | archive | help
* Peter Pentchev <roam@orbitel.bg> [001115 06:19] wrote: > All right, feel free to flame me a LOT for what follows :) No need for that. (yet) :-) > There are situations (at least I could think of some :) where it is necessary > to change a running process's credentials. I'm thinking specifically of the > effective UID and GID, but I might have to tinker with the real and saved > UID's, too. Well there's setuid for you. > As far as I can see, FreeBSD (nor any other Unix system I'm aware of) does not > provide a way to do this (short of writing to /dev/kmem ;). If a new syscall > should be implemented to this end, would it be enough to change a struct > proc's p_cred member, its pc_ucred and such, or would that raise hell all over > the process table? I see the comments mentioning 'possibly shared' > credentials - does this mean that I can inadvertently change the credentials > of a whole process children/siblings tree? That does not sound too good - > how do I go about taking a single process's credentials out - just allocate > a new pcred/ucred structure? Struct ucred is read-only, that would mean that strange things may happen, fortunatly at the moment most access control checks are only done at file open/socket bind time, so that if your cred changes you should still have access to it. > And yes, I'm quite aware of the security implications of something like > that.. let's just say I like playing with fire in a controlled environment :) > (famous last words..) Well there wouldn't be any security implications if done right... What comes to mind is using the cmsg stuff that's normally used to pass file descriptors and authentication information to pass the ability to setuid over to another application over a unix domain pipe. The recieving process would read using recvmsg determine if the passed uid is 'ok' (the kernel would hold it in the proc struct in a temporary), if it 'wanted' this uid it could then call some variation of setuid to switch to this recieved uid. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001115084722.I29448>