On Tue, Mar 26, 2002 at 03:59:32PM +0100, Oystein Viggen wrote: > I'm not so good at this, but I think what I mean is really "any way at > all you can accomplish what I describe". For a translator aware rm, we > need to be able to deal with any kind of user defined translator, not > just what we currently have.
This is true. As I showed you, we give the pick with the lock here :) > I should probably spend some time reading up on how things actually work > under the hood. I've been thinking mostly in terms of a user or a user > space programmer, in a kind of "press this pedal, and it goes faster" > fashion :) If you want to work on the fix, you will have to understand the problem, to the extent of knowing the pathname resolution very well. > > As root: > > mkdir test > > touch test/foo > > As user: > > settrans -ac test2 /hurd/firmlink test > > As root: > > rm -fR test2 > > I guess the important thing here is that rm will be doing its own > reading of test and get its own port to foo? Yes. test2 will ask it to retry on test, and rm complies. > > And test/foo will be gone. Note that in the tmpreaper function in > > libexec/rc, we are carefully removing translators first. > > This is nice, but I figure the program tmpreaper in debian does not. certainly not. > > Note that if you open node with O_NOFOLLOW, translators will not be > > followed, so some of such attacks are stopped by this. However, rm is > > not suspecting that a directory could be anything that it shouldn't > > follow. > > Do you mean O_NOTRANS? O_NOFOLLOW seems to be for symlinks, according > to fcntl.h. Actually both. O_NOFOLLOW implies O_NOTRANS in the Hurd, exactly to prevent such attacks, if the translator is not set by root. PLease read the long comment in glibc/hurd/lookup-retry.c about exactly this issue, and it doesn't harm to read the code, too :) > OK, so firmlink makes for a successful exploit, from a malicious users > point of view? If the sysadmin is "dumb" enough to do what you said, yes. > Then it needs to be, and so does a lot of other programs. (ah, finally > I found something I can probably work on ;) And then people always say that our todo lists are out of date. This has been part of the todo list long before even I joined in here. > > Seems so. You definitely have to be much more careful with rm -r in > > a space you don't own. > > userdel -r springs to mind. Definitely. I am out of time, so I will have to address the details later. Thanks, Marcus _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
