peter@ernie.NECAM.COM (Peter DiPrete) (11/09/88)
I surprised myself last week when I creamed the mail directory on our LAN
composed of Sun 3/60's, Sun 4/280, and Vax 8250 running Ultrix 2.3. The
surprise was that I wanted to clean off some files on a diskless client.
I used an "rm -r" on a filesystem "above" /usr/spool/mail (i think it was
/usr/spool, but I forget now). I was su'd to root at the time so as to be
sure I cleaned up thoroughly. It worked. Too well. The surprise is that
the mail filesystem is nfs mounted from the vax and I was working from one of
the (diskful) 60's. Since I "knew" root was translated into "nobody" over
the net, I was a little careless in my use of commands (next time, I'll
be sure to use "find . -xdev -exec rm {} \;"). I did not think that root ac
ross a NFS mount could do such damage (all mail was lost!).
So I experimented a little and found out that *anyone* at *anytime* can
blow away *any mailbox* since the mail directory has liberal permissions.
I even tried various combinations of set{gu}id and sticky bits on the directory.
I met with no success.
Here's the question, since the mail directory *must* have liberal
permissions to allow any user access to his/her mailbox, how can I
protect people's files. Even if a file has permissions set to 000,
any other user can blow it away! Can I protect people's mail better than this?
Actually, what I'd *really* like to do is to put people's mail in their home
directory since that would make NFS mounting the mail partition unneccessary.
Thanks in advance for all the help I know will come of this,
Peter Di Prete
NEC America
408-922-3829
{sun, uunet!altnet}!ernie!peter
--
Peter Di Prete @ NEC America
408-922-3829
sun!imagen!ernie!peter
...!uunet!altnet!ernie!peterchris@mimsy.UUCP (Chris Torek) (11/10/88)
In article <175@ernie.NECAM.COM> peter@ernie.NECAM.COM (Peter DiPrete) writes: >... the mail directory has liberal permissions. I even tried various >combinations of set{gu}id and sticky bits on the directory. The sticky bit on the directory is intended to fix that. Alas, it is broken in the NFS implementations you mentioned. You could try setting the spool directory to r-xr-xr-x, then make sure that two things still work: the first mail message to a user who has no spooled mail, and deleting all messages from spooled mail. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
mrm@sceard.UUCP (M.R.Murphy) (11/11/88)
In article <14466@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: |In article <175@ernie.NECAM.COM> peter@ernie.NECAM.COM (Peter DiPrete) writes: |>... the mail directory has liberal permissions. I even tried various |>combinations of set{gu}id and sticky bits on the directory. | |The sticky bit on the directory is intended to fix that. Alas, it is |broken in the NFS implementations you mentioned. You could try setting |the spool directory to r-xr-xr-x, then make sure that two things still |work: the first mail message to a user who has no spooled mail, and |deleting all messages from spooled mail. Note the ownerships, stickies, and permissions. drwxrwxr-x 2 root mail 256 Nov 10 10:21 /usr/mail -rwxr-sr-x 1 bin mail 25066 Oct 26 1985 /bin/lmail -rwxr-sr-x 1 bin mail 15000 Feb 17 1988 /bin/mail -rwxr-sr-x 2 bin mail 42292 Feb 17 1988 /bin/rmail -rwxr-sr-x 2 bin mail 42292 Feb 17 1988 /bin/smail -rwxr-sr-x 1 bin mail 99306 Oct 27 1985 /usr/bin/mailx Happens to be smail2.5, but the principles are the same with other mailers. -- Mike Murphy Sceard Systems, Inc. 544 South Pacific St. San Marcos, CA 92069 UUCP: {nosc,ucsd}!sceard!mrm INTERNET: mrm%sceard.UUCP@ucsd.ucsd.edu
mikef@wyn386.UUCP (Mike Faber) (11/12/88)
I have wondered something about permissions security for a while, now, too.
Why can a person with read permission only be able to remove the file? For
example, if I have a file of data (statistical data, for example), and I need
for any user in my group to read it as input data into their programs, they
will have read permission to it, but will also be able to remove it (it
makes sure you want to, but if Mr. Morris' worm had been destructive, he
could have wiped out anything that he had READ access to!!! Is there a point
I'm missing (Op systems back in college doesn't cover enough. THere ought to be
an ethics, or a security chapter in every O/S book.)
I'm more curious than worried, but there must be a reason...
--
_ _ | My employer and sysop do not think,
(/ (/ _ _ _ _ | so they cannot share my opinions.
(/) /\_(/_(/_/|_)_/ \_/ | Joe C Programmer (mikef@wynalda.uucp) work
(| (| | Michael Faber (sleepy@wybbs.uucp) playwoods@gpu.utcs.toronto.edu (Greg Woods) (11/14/88)
In article <850@sceard.UUCP> mrm@sceard.UUCP (0040-M.R.Murphy) writes: >In article <14466@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >|In article <175@ernie.NECAM.COM> peter@ernie.NECAM.COM (Peter DiPrete) writes: >|>... the mail directory has liberal permissions. I even tried various >|>combinations of set{gu}id and sticky bits on the directory. >| >|The sticky bit on the directory is intended to fix that. Alas, it is >|broken in the NFS implementations you mentioned. > >Note the ownerships, stickies, and permissions. >drwxrwxr-x 2 root mail 256 Nov 10 10:21 /usr/mail >-rwxr-sr-x 1 bin mail 25066 Oct 26 1985 /bin/lmail >-rwxr-sr-x 1 bin mail 15000 Feb 17 1988 /bin/mail >-rwxr-sr-x 2 bin mail 42292 Feb 17 1988 /bin/rmail >-rwxr-sr-x 2 bin mail 42292 Feb 17 1988 /bin/smail >-rwxr-sr-x 1 bin mail 99306 Oct 27 1985 /usr/bin/mailx >Happens to be smail2.5, but the principles are the same with other >mailers. I doubt you need set-group-id on mailx, since it only manipulates the user's own mailbox. Making it set-gid will allow anyone to read or write all system mailboxes. I've also found that no implementation of mailx or BSD Mail (that I've used) bothers to reset real uid and gid when spawning a sub-process, at least not when sending mail. If, for some reason, you find it necessary to have mailx delete empty mailboxes, and you aren't running a version of mailx which has a set-gid programme, usually called rmmail, for doing so, you should probably write one, and teach your users to use it, instead of making mailx set-gid. In general, use the K.I.S.S. principle with set-Xid programmes. -- Greg Woods. UUCP: utgpu!woods, utgpu!ontmoh!woods, lsuc!gate!woods VOICE: (416)443-1734 [h], (416)595-5425 [w] LOCATION: Toronto, Ontario, Canada
news@investor.UUCP ( Bob Peirce) (11/17/88)
In article <175@ernie.NECAM.COM> peter@ernie.NECAM.COM (Peter DiPrete) writes: > >Here's the question, since the mail directory *must* have liberal >permissions to allow any user access to his/her mailbox, how can I >protect people's files. Even if a file has permissions set to 000, >any other user can blow it away! Can I protect people's mail better than this? Our SysV mail has very restricted permissions. The directory has rwx for owner and group (mail) only and so do the files. All files are in the mail group and mail, I suppose, runs setgid mail. -- Bob Peirce, Pittsburgh, PA 412-471-5320 uucp: ...!{allegra, bellcore, cadre, idis, psuvax1}!pitt!investor!rbp NOTE: Mail must be < 30K bytes/message
barmar@think.COM (Barry Margolin) (11/17/88)
In article <189@wyn386.UUCP> mikef@wyn386.UUCP (Mike Faber) writes: >Why can a person with read permission only be able to remove the >file? ... if Mr. Morris' worm had been destructive, he >could have wiped out anything that he had READ access to!!! You are confused about what access is required to remove a file on Unix. The access you have to the file being removed has absolutely nothing to do with your ability to remove it; you can even remove files you have NO access to. You probably think this is even worse, because you now think that anyone can remove any file. That's not true, however. Removing files is considered an operation on the DIRECTORY. In order to remove a file, you must have write permission on the directory. The reasons for this are inherent in the Unix file system structure. A file may have any number of directory entries (hard links). Removing a link to a file doesn't necessarily affect the file, since other links to the file are unaffected. The file doesn't actually get wiped off the disk until the last link is removed and all openings of the file are closed. So, a destructive person/program CANNOT wipe out anything it has read access to, unless it is in a directory he has WRITE access to. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
debra@alice.UUCP (Paul De Bra) (11/17/88)
In article <189@wyn386.UUCP> mikef@wyn386.UUCP (Mike Faber) writes: > >I have wondered something about permissions security for a while, now, too. > >Why can a person with read permission only be able to remove the file?... The only think you need to delete a file is write permission in the directory containing the file. Permissions on the file have no effect whatsoever (except maybe giving a warning from rm). Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
ark@alice.UUCP (Andrew Koenig) (11/17/88)
In article <189@wyn386.UUCP>, mikef@wyn386.UUCP (Mike Faber) writes: > Why can a person with read permission only be able to remove the file? You can't remove a file; you can remove a link to a file. If that file has only one link, the file goes away automatically, as there is no longer any way to refer to it. (yes, I know this is slightly oversimplified) To remove a link, you need write permission for the directory containing the link, irrespective of the permissions you have for the file. -- --Andrew Koenig ark@europa.att.com
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/17/88)
In article <189@wyn386.UUCP> mikef@wyn386.UUCP (Mike Faber) writes: >Why can a person with read permission only be able to remove the file? He can't, unless he can remove the last link to the inode. Inode permissions apply to the contents of the inode, not to links to it (which are contained in other inodes). A link can be removed if a process has write permission on the directory containing the link.
trn%warper.jhuapl.edu@aplvax.jhuapl.edu (Tony Nardo) (11/18/88)
In article <189@wyn386.UUCP> mikef@wyn386.UUCP (Mike Faber) writes: | |I have wondered something about permissions security for a while, now, too. | |Why can a person with read permission only be able to remove the file? For |example, if I have a file of data (statistical data, for example), and I need |for any user in my group to read it as input data into their programs, they |will have read permission to it, but will also be able to remove it (it |makes sure you want to, but if Mr. Morris' worm had been destructive, he |could have wiped out anything that he had READ access to!!! Is there a point |I'm missing (Op systems back in college doesn't cover enough. THere ought to be |an ethics, or a security chapter in every O/S book.) A pity the implementers of UNIX didn't borrow one the idea of having a separate "delete" bit. It's one of a number of DEC features I miss. ============================================================================== ARPA: trn%warper@aplvax.jhuapl.edu (dumb mailers) BITNET: trn@warper.jhuapl.edu (also smart APRA mailers) UUCP: {backbone!}mimsy!aplcomm!warper!trn "Those who can do, those who can't teach. And those who can't do either become critics. That's why there's so many of them." A PORTRAIT OF THE ARTIST AS A YOUNG GOD ==============================================================================
francus@pernod.dec.com (Yoseff Francus) (11/18/88)
Michael Faber writes > I have wondered something about permissions security for a while, now, too. > > Why can a person with read permission only be able to remove the file? For > example, if I have a file of data (statistical data, for example), and I need > for any user in my group to read it as input data into their programs, they > will have read permission to it, but will also be able to remove it (it > makes sure you want to, but if Mr. Morris' worm had been destructive, he > could have wiped out anything that he had READ access to!!! Is there a point > I'm missing (Op systems back in college doesn't cover enough. THere ought to be > an ethics, or a security chapter in every O/S book.) > The permissons on a file have no bearing on whether the file may be deleted. In general it is write permission on the directory that determines which users can delete a file from a directory. Take the following example: The directory is called mydir, the name of the file is myfile. In all cases my permissions are world permission. A) permission on mydir is 755, permission on myfile is 666. In this case I can edit myfile, however I cannot delete it since I do not have write permission in mydir. B) permission on mydir is 777, on myfile it is 644. I cannot modify myfile but I can delete it. Think of a directory as a table of contents. You modify a table of contents by adding to it (adding a file) or deleting from it (deleting a file). Write permission on a directory allows you to modify the table of contents. Because of this keeping /tmp with a 777 permission is a potential problem. However, now the sticky bit can be set on a directory. If the sticky bit is set only the owner of a file may delete that file no matter what permissions are set on the directory. The owner though must still have write permission for that give directory otherwise he still won't be able to delete the file. Adding the sticky bit is an additional layer of protection. Yoseff In Xanadu did Kubla Khan A stately pleasure dome decree But only if the NFL To a franchise would agree yf%pernod.dec@decwrl.dec.com
crossgl@ingr.UUCP (Gordon Cross) (11/18/88)
In article <189@wyn386.UUCP>, mikef@wyn386.UUCP (Mike Faber) writes: > > Why can a person with read permission only be able to remove the file? If you have write access to a directory, you can remove any file it contains regardless of the permissions set for that file. This "feature" is not a security hole even though it would seem so. I have never liked the way it works either since I occasionally desire to protect a file from accidental deletion (as one can under VMS). At least rm does ask... Gordon Cross Intergraph Corp. Huntsville, AL ...uunet!ingr!crossgl
gwyn@smoke.BRL.MIL (Doug Gwyn ) (11/18/88)
In article <2470@aplcomm.jhuapl.edu> trn%warper.jhuapl.edu@aplvax.jhuapl.edu (Tony Nardo) writes: >A pity the implementers of UNIX didn't borrow one the idea of having a >separate "delete" bit. It's one of a number of DEC features I miss. What in the world would it MEAN? It is the DIRECTORY that is modified by an unlink, not the inode. Would a "delete" bit then mean that no links to the inode could be removed? Think about the consequences for a bit. It would be horrible!
frank@Morgan.COM (Frank Wortner) (11/19/88)
In article <8910@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: } [...] }Inode permissions apply to the contents of the inode, not to }links to it (which are contained in other inodes). } [...] Perhaps I've failed to understand what you wrote. I've always thought that non-symbolic links were directory entries pointing to the *same* inode, and that any permissions (read, write, and execute of the underlying object) were shared by all links. -- Frank "Computers are mistake amplifiers."
mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield (Mike)) (11/19/88)
In article <8927@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <2470@aplcomm.jhuapl.edu> trn%warper.jhuapl.edu@aplvax.jhuapl.edu (Tony Nardo) writes: >>A pity the implementers of UNIX didn't borrow one the idea of having a >>separate "delete" bit. It's one of a number of DEC features I miss. >What in the world would it MEAN? It is the DIRECTORY that is modified >by an unlink, not the inode. Would a "delete" bit then mean that no >links to the inode could be removed? Think about the consequences for >a bit. It would be horrible! Nope. Sound great as long as it was in addition to directory permissions and not instead of directory permissions. Doesn't sound too good when you say you will allow or disallow delete permission on all the files in a directory regardless of the nature of the individual files. Maybe some of the definition needs refining but it sure could fix more problems than it casues! Michael H. Warfield (The Mad Wizard) | gatech.edu!galbp!wittsend!mhw (404) 270-2123 / 270-2098 | mhw@wittsend.LBP.HARRIS.COM An optimist believes we live in the best of all possible worlds. A pessimist is sure of it!
stever@tree.UUCP (Steve Rudek) (11/19/88)
In article <31681@think.UUCP>, barmar@think.COM (Barry Margolin) writes: > You probably think this is even worse, because you now think that > anyone can remove any file. That's not true, however. Removing files > is considered an operation on the DIRECTORY. In order to remove a > file, you must have write permission on the directory. Yeah, unfortunately write permission to a file or directory is an all-or-nothing matter. You can't give permission to add a new file to a directory without also granting permission to wipe out everything in that directory, can you? For example, I'd like to set up a directory for source code contributions from our users. Folks should be able to cp source in but not modify (or erase!) other peoples contributions. A fourth file access mode, enforced by the kernel, would be nice: an "append" mode would allow people to add files to a directory or add text to a file but NOT remove files from a directory nor molest the existing contents of a file. It occurs to me that the setuid/setgid idea was a clever kludge. Like many kludges it solved obvious problems at the expense of creating more pernicious ones. Much of the need for setuid (scripts, especially) would disappear if a decent way existed to to protect the integrity of existing files in a directory. Perhaps the kernel should consult *both* the directory permissions AND the specific file permissions before deciding on access rights? I haven't thought this through, but what if people (other than the owner of the directory) needed write permission to BOTH the directory AND the file in order to rm it?
grs@alobar.ATT.COM (Gregg Siegfried) (11/19/88)
In article <2955@ingr.UUCP> crossgl@ingr.UUCP (Gordon Cross) writes: >If you have write access to a directory, you can remove any file it contains >regardless of the permissions set for that file. This "feature" is not a >security hole even though it would seem so. I have never liked the way it >works either since I occasionally desire to protect a file from accidental >deletion (as one can under VMS). At least rm does ask... This discussion seems to arise fairly frequently in some of these newsgroups. I think it's worthwhile to note that in SVR3.2 (and presumably 4.0) this is no longer necessarily the case. By setting the sticky bit (chmod 1xxx file) on a directory, users are prevented from removing any files from that directory except those that they own, even if the directory permissions are 777. I know that /tmp and /usr/tmp are configured this way by default in 3.2. >Gordon Cross Gregg Siegfried grs@alobar.att.com AT&T doesn't speak for me, nor I for them.
waters@polya.Stanford.EDU (Jim Waters) (11/19/88)
In article <145@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes: >Yeah, unfortunately write permission to a file or directory is an >all-or-nothing matter. You can't give permission to add a new file to >a directory without also granting permission to wipe out everything in >that directory, can you? Well, that depends which Unix you're running. Ultrix sticky(8) reads: A directory whose `sticky bit' is set becomes an append-only directory, or, more accurately, a directory in which the deletion of files is resrticted. A file in a sticky direc- tory may only be removed pr renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, the super- user. This feature is usefully applied to directories such as /tmp which must be publicly writeable but should deny users the license to arbitrarily delete or rename each oth- ers' files. Of course, that's just Ultrix.... --------------------------------------------------------------------------- Jim Waters INTERNET: waters@umunhum.stanford.edu USPS: P.O. Box 13735 waters@argus.stanford.edu Stanford, CA 94309 UUCP: ...decwrl!umunhum.stanford.edu!waters AT+T: (415)323-3063 BITNET: waters%umunhum.stanford.edu@stanford
roy@phri.UUCP (Roy Smith) (11/20/88)
mikef@wyn386.UUCP (Mike Faber) writes: > Why can a person with read permission only be able to remove the file? I'm not sure I understand what Mike is getting at, but it sounds like he has a directory which is world-writable with a read-only file in it. If this is the situation, then yes, people can remove the read-only file. This is rather counter-intuitive, but a straight-forward result of the file system semantics. All Mike need do is make sure that the directory in which his file resides is not world-writable and he should be OK. Berkeley systems (and maybe others?) have a "sticky directory" feature which allows people to create files in publicly writeable directories (i.e. /tmp) without letting other people remove or rename them. At least on my system (MtXinue 4.3BSD/NFS) I havn't gotten stickey directories to work properly; possibly I'm just doing something wrong? -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net "The connector is the network"
pat@orac.UUCP (Pat Barron) (11/21/88)
In article <145@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes: >Yeah, unfortunately write permission to a file or directory is an >all-or-nothing matter. You can't give permission to add a new file to >a directory without also granting permission to wipe out everything in >that directory, can you? 4.3BSD lets you do this. If you set the "sticky bit" on a directory, then nobody will be able to remove files from that directory that they don't own, even if the directory permissions say otherwise. Lots of sites have /usr/tmp mode 1777 (read/write/execute by all, with sticky bit). You can add files, and remove them when you're done, but you can't unlink someone else's file. --Pat.
guy@auspex.UUCP (Guy Harris) (11/22/88)
>Well, that depends which Unix you're running. Ultrix sticky(8) reads: > > A directory whose `sticky bit' is set becomes an append-only > directory, or, more accurately, a directory in which the > deletion of files is resrticted. ... >Of course, that's just Ultrix.... Actually, it's 4.3BSD, and Ultrix, and SunOS 4.0 (and maybe some earlier SunOS 3.x release), and possibly System V Release 3.2, and....
allbery@ncoast.UUCP (Brandon S. Allbery) (11/22/88)
As quoted from <1988Nov13.192003.22144@gpu.utcs.toronto.edu> by woods@gpu.utcs.toronto.edu (Greg Woods): +--------------- | In article <850@sceard.UUCP> mrm@sceard.UUCP (0040-M.R.Murphy) writes: | >Note the ownerships, stickies, and permissions. | >drwxrwxr-x 2 root mail 256 Nov 10 10:21 /usr/mail | >-rwxr-sr-x 1 bin mail 25066 Oct 26 1985 /bin/lmail | >-rwxr-sr-x 1 bin mail 15000 Feb 17 1988 /bin/mail | >-rwxr-sr-x 2 bin mail 42292 Feb 17 1988 /bin/rmail | >-rwxr-sr-x 2 bin mail 42292 Feb 17 1988 /bin/smail | >-rwxr-sr-x 1 bin mail 99306 Oct 27 1985 /usr/bin/mailx | >Happens to be smail2.5, but the principles are the same with other | >mailers. | | I doubt you need set-group-id on mailx, since it only manipulates the | user's own mailbox. Making it set-gid will allow anyone to read or | write all system mailboxes. I've also found that no implementation of | mailx or BSD Mail (that I've used) bothers to reset real uid and gid | when spawning a sub-process, at least not when sending mail. +--------------- Don't try this at home, kids. If you're unlucky enough to have a mailer which uses links to lock mailboxes, mailx MUST be set[ug]id (which depends on whether you run your primary mailer [/bin/mail] setuid or setgid). As far as I know, all System V's still use links because someone was afraid that record locks can't emulate file locks. (hmph; just lock the byte AFTER eof!) ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery <PREFERRED!> ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu <ALSO> allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
rbj@nav.icst.nbs.gov (Root Boy Jim) (11/23/88)
? From: Doug Gwyn <gwyn@smoke.brl.mil>
? In article <2470@aplcomm.jhuapl.edu> trn%warper.jhuapl.edu@aplvax.jhuapl.edu (Tony Nardo) writes:
? >A pity the implementers of UNIX didn't borrow one the idea of having a
? >separate "delete" bit. It's one of a number of DEC features I miss.
? What in the world would it MEAN? It is the DIRECTORY that is modified
? by an unlink, not the inode. Would a "delete" bit then mean that no
? links to the inode could be removed? Think about the consequences for
? a bit. It would be horrible!
I'm not so sure. VMS has just that, and seems to work OK (did I actually
say that?). It also has a set of system bits that apply only to the
system account. How nice it would be to be able to be able as root to
chmod a file to some mode and then not be able to delete it before
chmod'ing it back to something else.
I have often felt that UNIX cramming mode and type bits together was
somewhat limiting. Perhaps 16 bits for the mode a la VMS is a bit much,
and the semantics would have to be rethought (yes, it is the directory
that is modified, but the rm command attempts to give the file something
to say about it, and the kernel could do the same), but think of all
the FEECHURS we could add to the kernel!!! :-)
(Root Boy) Jim Cottrell (301) 975-5688
<rbj@nav.icst.nbs.gov> or <rbj@icst-cmr.arpa>
Crackers and Worms -- Breakfast of Champions!woods@gpu.utcs.toronto.edu (Greg Woods) (11/23/88)
In article <13155@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: > As quoted from <1988Nov13.192003.22144@gpu.utcs.toronto.edu> by woods@gpu.utcs.toronto.edu (Greg Woods): > | I doubt you need set-group-id on mailx, since it only manipulates the > | user's own mailbox. Making it set-gid will allow anyone to read or > | write all system mailboxes. I've also found that no implementation of > | mailx or BSD Mail (that I've used) bothers to reset real uid and gid > | when spawning a sub-process, at least not when sending mail. > > Don't try this at home, kids. > > If you're unlucky enough to have a mailer which uses links to lock mailboxes, > mailx MUST be set[ug]id (which depends on whether you run your primary > mailer [/bin/mail] setuid or setgid). As far as I know, all System V's > still use links because someone was afraid that record locks can't emulate > file locks. (hmph; just lock the byte AFTER eof!) I have no doubt that Brandon is right. I hope that anyone who has found this security hole in mailx hasn't also lost mail by disabling the ability of mailx to lock their mailbox. I have been somewhat confused over time, since I've known that BSD Mail doesn't require set-id, nor does mush. Mush uses lockf() [or locking()], and I assume Mail does the same. Of interest, the mailx I have running on our Unix-PC at work (mailx2.14) doesn't complain about not being able to lock the mailbox, though it does exhibit lots of strange behavior. I attributed the faults to bugs, but maybe that's its way of complaining. Some of our users have lost mailboxes. :-( This leaves open the question as to why mailx has a special set-[ug]id programme (rmmail) to remove empty mailboxes. If mailx must itself be set-id, then rmmail is useless. If your mailx must write to the system spool directory, and it exhibits the security violation, you'd better complain to your vendor, and fast, before everyone reads your mail. 1/4 :-) -- Greg Woods. {utgpu,lsuc!gate,ontmoh}!woods, woods@{gpu.utcs.Toronto.EDU,utorgpu.BITNET} 1-416-443-1734 [h], 1-416-595-5425 [w] LOCATION: Toronto, Ontario, Canada
guy@auspex.UUCP (Guy Harris) (11/24/88)
>? What in the world would it MEAN? It is the DIRECTORY that is modified >? by an unlink, not the inode. Would a "delete" bit then mean that no >? links to the inode could be removed? Think about the consequences for >? a bit. It would be horrible! > >I'm not so sure. VMS has just that, and seems to work OK (did I actually >say that?). VMS has hard links, but I don't think it makes much use of them. For one thing, there are no reference counts associated with them. Removing a file, and removing a directory entry that points to a file, are as I understand it ultimately separate operations. Does the "delete" permission bit affect both, or only the former? The situations are not quite parallel. Now you could conceivably require that special permission be required to remove the *last* link to a file; I don't know whether this necessary would do what people really want here, though, and I thus don't know whether adding this feechur would be worth it.
ka@june.cs.washington.edu (Kenneth Almquist) (11/26/88)
grs@alobar.ATT.COM (Gregg Siegfried) writes: > By setting the sticky bit (chmod 1xxx > file) on a directory, users are prevented from removing any files from that > directory except those that they own, even if the directory permissions are > 777. That means that I can create directory entries which I can't delete. Yuck! I would think that the rule, "You can delete anything that you create," would be a *minimum* sanity check for a security model. I mean, if system security really depends upon the existence of some object which I created, then I could defeat system security by not creating the object in the first place, rather than by deleting the object later. I'm not sure what problem this "feature" is supposed to solve, anyway. Presumably the problem that programs store temp files in /tmp, where they can be deleted by anyone? The obvious solution is to fix the programs. It would certainly possible for AT&T to give each user his or her own temporary directory and to modify the standard System V programs to use this directory. Third party software might continue to use /tmp for a long time (old binaries and all that), but is the /tmp problem really all that pressing? We've lived with /tmp for the last 20 years; just how awful would it be if a few programs continued to use it for the next few? And even with this sticky bit "feature" /tmp can still be attacked by immature users; just create enough files there and the access time will increase to unacceptable levels. Kenneth Almquist
barmar@think.COM (Barry Margolin) (11/28/88)
In article <6527@june.cs.washington.edu> ka@june.cs.washington.edu (Kenneth Almquist) writes: >grs@alobar.ATT.COM (Gregg Siegfried) writes: >> By setting the sticky bit (chmod 1xxx >> file) on a directory, users are prevented from removing any files from that >> directory except those that they own, even if the directory permissions are >> 777. >I'm not sure what problem this "feature" is supposed to solve, anyway. [He presumes it is for /tmp, and suggests each user have his own temp-dir.] No, I think it was invented specifically for /usr/spool/mail. Everyone must be able to remove or rename his incoming mail file. Giving each user his own subdirectory of /usr/spool/mail might be a possibility, but it would be an incompatible change that would affect many mail-reading/sending facilities that know about /usr/spool/mail. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar