Xref: utzoo comp.unix.admin:1902 alt.security:2592
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!umich!ox.com!fmsrl7!art-sy!news
From: chap@art-sy.detroit.mi.us (j chapman flack)
Newsgroups: comp.unix.admin,alt.security
Subject: Re: setuid (was Re: Non Destructive Version of rm)
Keywords: setuid risks
Message-ID: <9105200808.aa02147@art-sy.detroit.mi.us>
Date: 20 May 91 12:08:33 GMT
References: <1991May3.212619.21119@casbah.acns.nwu.edu>
            <JIK.91May6001507@pit-manager.mit.edu>
            <9105130857.aa02726@art-sy.detroit.mi.us>
            <1991May14.101450.830@convex.com>
Reply-To: chap@art-sy.detroit.mi.us (j chapman flack)
Distribution: na
Organization: Appropriate Roles for Technology
Lines: 24

In article <1991May14.101450.830@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
>Here's Henry Spencer's setuid(7) man page.  I keep wanting to 
 ...

And a very useful man page it is.  I'll hang on to that.

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?

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?

...not arguing with the statements, just trying to understand the risks...

-- 
Chap Flack                         Their tanks will rust.  Our songs will last.
chap@art-sy.detroit.mi.us                                    -MIKHS 0EODWPAKHS

Nothing I say represents Appropriate Roles for Technology unless I say it does.