setuid (was Re: Non Destructive Version of rm)

Tom Christiansen tchrist at convex.COM
Tue May 21 22:15:55 AEST 1991


>From the keyboard of chap at art-sy.detroit.mi.us (j chapman flack):
:The man page mentions that on "some" systems pwd(1) does not run setuid-root
:and so can't pwd if the parent or an ancestor directory is unreadable.
:
:My system is one of those.  Is there something intrinsically unsafe about pwd
:that would create holes if I made it setuid-root?

I can't really think of anything, but this is scant evidence, let alone
proof, of trustworthiness.  Most of us seem to get by find without a suid
pwd(1).  It fails whenever a normal getwd(3) would fail, but few of us
consider this critical.  So what?  The fewer suid programs (and the fewer
programs root always runs) the less you have to worry about.  And I don't
think implementing getwd(3) via a popen(3) to a suid pwd(1) is a very
elegant solution.

:Also, I'm not sure I understand the effect of the resource-depletion types
:of attacks.  Someone recently suggested by email that a program can be made
:to crash and leave the user in a privileged shell.  When a program bombs,
:doesn't its (privileged) process disappear?

I've heard people say this, too, but it makes little sense.  All I 
can imagine is that the program might be coerced into giving you 
a NEW, interactive, privileged shell.  It would have to be a very
naughty program to change the uid/gid privs of its calling process,
although as I've shown before, it can be done if you poke kmem.

--toim
--
Tom Christiansen		tchrist at convex.com	convex!tchrist
		"So much mail, so little time." 



More information about the Comp.unix.admin mailing list