tchrist@convex.COM (Tom Christiansen) (12/06/90)
In article <1990Dec6.005358.6336@dg-rtp.dg.com> goudreau@larrybud.rtp.dg.com (Bob Goudreau) writes:
:Yup, it's true. System V has avoided this blemish from BSD.
Sounds semi-religious to me. Blemish?
:But note that the SVID also mandates that a chown() will result in
:the set-UID and set-GID bits being cleared (unless the process has
:"appropriate privileges"). Otherwise, the system would have a gaping
:security hole: I could create a file, chmod() it to mode 4755, chown()
:it to root, and voila: I have a setuid root program!
I consider non-superuser chown(2)s harmful. They screw up anyone who's
trying to do post-facto disk accounting or pre-emptive disk quotas.
Believe it or not, a lot of sites really do use one or both of these,
and giving away files makes this effectively useless. These aren't
solely educational sites either.
It also ruffles my security feathers. Various programs realize that they
shouldn't source config files owned by someone other than the current
user, such as vi and the csh. If I make a /tmp/.exrc, and someone cd's to
/tmp and vi's some file there, I still won't trick someone into sourcing
it because I can't make them own it. The wide-open chown(2) call rampant
at Death Star sites makes these security attempts futile.
--tom
--
Tom Christiansen tchrist@convex.com convex!tchrist
"With a kernel dive, all things are possible, but it sure makes it hard
to look at yourself in the mirror the next morning." -merickert@mp.cs.niu.edu (Neil Rickert) (12/07/90)
In article <109958@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: >I consider non-superuser chown(2)s harmful. They screw up anyone who's >trying to do post-facto disk accounting or pre-emptive disk quotas. > >It also ruffles my security feathers. Various programs realize that they >shouldn't source config files owned by someone other than the current >user, such as vi and the csh. If I make a /tmp/.exrc, and someone cd's to I wonder whether 'sendmail' checks for this. If the system aliases file contains :include:/path/name as an alias, when the alias is expanded 'sendmail' uses the permissions of the owner of the :include: file for aliases such as "|program". (permission of daemon for a root owner). If SystemV versions of 'sendmail' don't change this, and allow giving away files, then anyone given access to manage a mailing list has almost carte-blanche to execute programs as other people. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/07/90)
In article <109958@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: > I consider non-superuser chown(2)s harmful. They screw up anyone who's > trying to do post-facto disk accounting or pre-emptive disk quotas. There is, however, one case where non-superuser chown()s would greatly help security. Setuid programs should to be able to switch files between the real and effective uids. Because this feature isn't available, many secure programs have to run as root rather than their own uids. ---Dan
jfh@rpp386.cactus.org (John F Haugh II) (12/07/90)
In article <109958@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: >I consider non-superuser chown(2)s harmful. They screw up anyone who's >trying to do post-facto disk accounting or pre-emptive disk quotas. >Believe it or not, a lot of sites really do use one or both of these, >and giving away files makes this effectively useless. These aren't >solely educational sites either. If an operating system can support unlink() and creat()/open() in a quota environment, there is NO reason it cannot support chown(). As for the annoying aspects of non-superuser chown(), such as mischevious users, that's an administrative problem. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
goudreau@larrybud.rtp.dg.com (Bob Goudreau) (12/08/90)
In article <109958@convex.convex.com>, tchrist@convex.COM (Tom Christiansen) writes: > > :Yup, it's true. System V has avoided this blemish from BSD. > > Sounds semi-religious to me. Blemish? Yes, blemish. Even BSD's own man page for chmod(2) admits that this behavior comes "at the expense of a degree of compatibility". ---------------------------------------------------------------------- Bob Goudreau +1 919 248 6231 Data General Corporation goudreau@dg-rtp.dg.com 62 Alexander Drive ...!mcnc!rti!xyzzy!goudreau Research Triangle Park, NC 27709, USA
karish@mindcraft.com (Chuck Karish) (12/08/90)
In article <18786@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >As for the annoying aspects of non-superuser chown(), such as >mischevious users, that's an administrative problem. It certainly is. And non-superuser chown() destroys information that's vital for some administrative tasks. That's why FIPS 151-1 mandates that the POSIX.1 _POSIX_CHOWN_RESTRICTED option be supported. -- Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000
peter@ficc.ferranti.com (Peter da Silva) (12/08/90)
In article <109958@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: > If I make a /tmp/.exrc, and someone cd's to /tmp and vi's some file there, > I still won't trick someone into sourcing it because I can't make them own > it. Sounds like a bug in 'vi'. It really shouldn't source anything but ~/.exrc or (even better) run $EXINIT: you can put all your .exrc munging in there. Programs that build in a security hole then try to patch it over are far worse than a well-documented system call. As for quotas: disable the call if you're running quotas, otherwise leave it alone. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
peter@ficc.ferranti.com (Peter da Silva) (12/08/90)
In article <1990Dec7.032340.13531@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > I wonder whether 'sendmail' checks for this. If the system aliases > file contains :include:/path/name as an alias, when the alias is > expanded 'sendmail' uses the permissions of the owner of the :include: > file for aliases such as "|program". That's a bug in sendmail. Is anyone surprised? After all, you can always fake it out by sending mail to your target with appropriate lines in it, then set your aliases file to point to their mailbox file (/usr/mail/user)... Who else can think of a hole like this? > If SystemV versions of 'sendmail' ... What a horrible idea! -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
jfh@rpp386.cactus.org (John F Haugh II) (12/08/90)
In article <1990Dec7.171501.18028@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > What do you mean by 'support chown()'. Should another field be added >to the 'inode' specifying the 'real owner' to be used for permissions, >and chown() by other than root preserves this 'real owner' field. This is >adding too much complexity. Disallowing non-root access to chown() is >simpler, more effective, and safer. The context of the thread was that chown() messes up the quota mechanism, and is therefore evil. This is the common excuse, and is often used as the justification for BSD not supporting non-root chown(). However, this is silly. If the system can properly maintain quotas with open/creat and unlink calls being made, there is no reason it cannot properly maintain quotas with chown() system calls. Other arguments are that you shouldn't be able to give someone a file, for some mystery reason, where "some mystery reason" often comes down to users who circumvent their quota by changing the ownership to someone else, and maintaining read/write access to the file after giving it away. This is an administrative problem, and as such the policy should be administrative. The result of making a system call "root-only" is that any application which might have a legitimate need to execute that function must be set-uid to root in order to perform that now privileged operation. For example, if all the unallocated TTY devices were owned by "uucp", all the applications which deal with TTY devices would only have to be set-UID to "uucp". Unfortunately, if you have an application that wants to change the ownership to the user, such as cu, you must now make cu set-UID to "root". -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
jay@silence.princeton.nj.us (Jay Plett) (12/08/90)
In article <18786@rpp386.cactus.org>, jfh@rpp386.cactus.org (John F Haugh II) writes: > If an operating system can support unlink() and creat()/open() in a > quota environment, there is NO reason it cannot support chown(). Would you please elaborate? > As for the annoying aspects of non-superuser chown(), such as > mischevious users, that's an administrative problem. As you say (though perhaps not as you meant), it does indeed create a serious administrative problem. ...jay
tchrist@convex.COM (Tom Christiansen) (12/08/90)
As was pointed out to me by Dick Dunn <rcd@ico.isc.com>, there's also the problem of being able to create files you can't get rid of or touch without superuser intervention. A tar or cpio extract of directories containing files owned by another user will create this scenario. Once the directory is owned by someone else, you can't change it back, so you can't delete the files, and you can't delete the directory because it's not empty. You shouldn't have to get superuser help to fix something you yourself did. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." -me
jfc@athena.mit.edu (John F Carr) (12/08/90)
BSD 4.3 does not enforce quota if the quota limit for a userid is zero (for
example, if quota has not been set for a user). This means if you don't set
a quota for every possible userid and non-superuser chown()s are allowed, a
user can give away files to a userid without quota to get unlimited storage.
We've made several changes to the quota system here; one of them is to
optionally disallow storage of files by any user who has not explicitly been
given a quota.
--
John Carr (jfc@athena.mit.edu)tchrist@convex.COM (Tom Christiansen) (12/08/90)
In article <18792@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >The context of the thread was that chown() messes up the quota mechanism, >and is therefore evil. That's one reason. I think there are others. Being able to make an arbitrary file belong to another user seems almost as bad as making an arbitrary file owned by you. It runs against my intuitive feel for what the ownership of a file really is. If I want to know whose file this is, should I mail every user on the system, or should I examine the owner field in the inode? Some programs rely on the ownership of a file to make inferences about what is a safe and reasonable operation vis-a-vis security. I'm not ready to accept that programs that do this a "just stupid broken BSD hacks" as the ATT folks maintain. It also bother me that I can create files that I can no longer unlink or even access without superuser assistance. >The result of making a system call "root-only" is that any application >which might have a legitimate need to execute that function must be >set-uid to root in order to perform that now privileged operation. >For example, if all the unallocated TTY devices were owned by "uucp", >all the applications which deal with TTY devices would only have to >be set-UID to "uucp". Unfortunately, if you have an application that >wants to change the ownership to the user, such as cu, you must now >make cu set-UID to "root". Yes, there is that unfortunate consequence. No one ever said the all-or-nothing way of doing superuser privileges on UNIX was the optimal route. That's why a lot of us have written interfaces to provide limited superuser access. See the sudo.c program in Evi Nemeth's sysadmin book, or read about the op program I describe in the LISA-3 proceedings. If you could switch a file's ownership between real and effective uid's, this wouldn't be a problem. Since a process can always cp a file, at which time it will be owned by whichever ID was active at the time, I don't see why that can't be allowed. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." -me
rickert@mp.cs.niu.edu (Neil Rickert) (12/09/90)
In article <18792@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >In article <1990Dec7.171501.18028@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >> What do you mean by 'support chown()'. Should another field be added >>to the 'inode' specifying the 'real owner' to be used for permissions, >>and chown() by other than root preserves this 'real owner' field. This is >>adding too much complexity. Disallowing non-root access to chown() is >>simpler, more effective, and safer. > >The context of the thread was that chown() messes up the quota mechanism, >and is therefore evil. This is the common excuse, and is often used as >the justification for BSD not supporting non-root chown(). > >However, this is silly. If the system can properly maintain quotas >with open/creat and unlink calls being made, there is no reason it >cannot properly maintain quotas with chown() system calls. > Why do you completely misinterpret what people are saying. The problem with quotas and non-root chown is that the file is charged against the new owner, and the ability to chown allows one to circumvent limits applied. Any different meaning of quotas would mean that the system would have to read the system administrator's mind as to who should be charged for the file space. > >The result of making a system call "root-only" is that any application >which might have a legitimate need to execute that function must be >set-uid to root in order to perform that now privileged operation. >For example, if all the unallocated TTY devices were owned by "uucp", >all the applications which deal with TTY devices would only have to >be set-UID to "uucp". Unfortunately, if you have an application that >wants to change the ownership to the user, such as cu, you must now >make cu set-UID to "root". Non superuser chown() doesn't solve this problem. It at best provides a half-baked solution, for it can leave the user owning the TTY and uucp being able to reclaim it. A better solution here would be to have a way of changing the ownership of the TTY only on the in-memory copy of the inode, but never writing this changed ownership back to disk. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
karish@mindcraft.com (Chuck Karish) (12/09/90)
In article <110064@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: >As was pointed out to me by Dick Dunn <rcd@ico.isc.com>, there's also the >problem of being able to create files you can't get rid of or touch >without superuser intervention. A tar or cpio extract of directories >containing files owned by another user will create this scenario. Once >the directory is owned by someone else, you can't change it back, so you >can't delete the files, and you can't delete the directory because it's not >empty. The tar and cpio utilities on systems with privileged chown() should restore files and directories with the extractor's ID as owner, unless done with superuser privileges. Many tar implementations don't store directories anyway, so the directories are created as needed on extraction and are owned by the current user. How should permissions be set on extraction from an archive? Should setuid bits be honored? -- Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000
rickert@mp.cs.niu.edu (Neil Rickert) (12/09/90)
In article <660691624.18045@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes: >How should permissions be set on extraction from an archive? Should >setuid bits be honored? They probably should not be honored. But changing the rules to not honor suid bits on extraction from tar tapes sure would make life more difficult for vendors when they distribute new binary software releases. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
tchrist@convex.COM (Tom Christiansen) (12/09/90)
In article <660691624.18045@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes: >The tar and cpio utilities on systems with privileged chown() should >restore files and directories with the extractor's ID as owner, unless >done with superuser privileges. Yes, but what happens where chown is not privileged? % mkdir foo % touch foo/bar % chown somebody_else foo/bar foo Now how do I get rid of that stuff? >How should permissions be set on extraction from an archive? Should >setuid bits be honored? I tend to prefer them to be maintained, even if it does seem to invite mischief. It makes it hard to copy directories around otherwise. I once tried to disable this and found it sure broke a lot of things. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." -me
johnl@iecc.cambridge.ma.us (John R. Levine) (12/09/90)
In article <1990Dec8.184047.22221@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > Why do you completely misinterpret what people are saying. The problem >with quotas and non-root chown is that the file is charged against the >new owner, and the ability to chown allows one to circumvent limits applied. > > Any different meaning of quotas would mean that the system would have to >read the system administrator's mind as to who should be charged for the >file space. Does anyone really do quota accounting by the UID of the file? Consider the following scenario: User A creates a large file. User B links to it. User A then deletes the original link. If you charge by uid, user A is charged for the file even though she has no control over it any more, and might not even be able to see that it exists, depending on B's directory protections. It seems to me that the only plausible way to charge for space is to assign charge responsibility for each directory (with the default being that a directory is charged to the same user as its parent, so you only have to list users' home directories) and to add up the sizes of the files in all of s user's directory, charging 1/Nth of the blocks in an N block file, rounded up. If users can link to shared public files, you might want to make a pre-pass that collects the inumbers of public files and not charge users for links to them. I did this kind of quota (without the public file hack) under 6th edition Unix at Yale in 1976. It's no big deal. Note that none of this depends on UIDs. I suppose you might want to restrict chowns on directories to keep users from ending up with inacessible subtrees, though it's easy enough to write a privileged recovery utility that would chmod a directory to 777 if it's a descendant of the user's home. -- John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!iecc!johnl "Typically supercomputers use a single microprocessor." -Boston Globe
rcpieter@svin02.info.win.tue.nl (Tiggr) (12/09/90)
rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <660691624.18045@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes: >>How should permissions be set on extraction from an archive? Should >>setuid bits be honored? > They probably should not be honored. But changing the rules to not honor >suid bits on extraction from tar tapes sure would make life more difficult >for vendors when they distribute new binary software releases. The 07000 bits *should* be honoured to be able to do proper backups (as root). If chown is a privileged call (as in BSD) normal users always extract files with the user's userid, and root may choose to force uid=0 or to use the uids as present in the tarchive. Using this scheme there is no problem (the mere idea of being able to do something to a file as a normal user, causing that you must become superuser to undo it is horrible anyway). Just my two BSD-minded cents, Tiggr
tchrist@convex.COM (Tom Christiansen) (12/09/90)
In article <1990Dec09.043647.25826@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes: >Does anyone really do quota accounting by the UID of the file? Absolutely. I know a good number of both university and commercial sites that do so, using either the original BSD system or the one modified for use with NFS. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." -me
jfh@rpp386.cactus.org (John F Haugh II) (12/10/90)
In article <110075@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: >If you could switch a file's ownership between real and effective uid's, >this wouldn't be a problem. Since a process can always cp a file, at >which time it will be owned by whichever ID was active at the time, I >don't see why that can't be allowed. Yes, and this is a much better solution - restrict chown() to be between the real and effective UIDs, rather that completely out the window. It does solve the problem of privileged subsystems (such as CU and UUCP) being able to flip a file over to another user and back again. However, in a co-operative environment (such as commercial installations) there is quite a bit of file-sharing going on in a very ad hoc fashion. User's should not be forced to contact an administrator, or perform file access mode mumbo-jumbo to give a file away. Why FIPS went with chown() being restricted is a mystery ... -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/10/90)
In article <18792@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > The result of making a system call "root-only" is that any application > which might have a legitimate need to execute that function must be > set-uid to root in order to perform that now privileged operation. > For example, if all the unallocated TTY devices were owned by "uucp", > all the applications which deal with TTY devices would only have to > be set-UID to "uucp". Unfortunately, if you have an application that > wants to change the ownership to the user, such as cu, you must now > make cu set-UID to "root". Exactly. This is why several people have been arguing for chown() to work between current and effective uids. Does chown() have any other reasonable use? ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/10/90)
In article <1990Dec09.043647.25826@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes: > Does anyone really do quota accounting by the UID of the file? Consider > the following scenario: User A creates a large file. User B links to it. > User A then deletes the original link. If you charge by uid, user A is > charged for the file even though she has no control over it any more, and > might not even be able to see that it exists, depending on B's directory > protections. That's not an argument against normal quota accounting. It's an argument for a user to have better control over files he owns. Somewhere in my BSD-extensions list is a destroy(fd) system call to eliminate all references to a given file other than the current descriptor. There's also openfuid()/readfuid()/closefuid() to walk through all files owned by a given user/group/ACL/everybody/whatever in inode order. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/10/90)
In article <18796@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > In article <110075@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: > >If you could switch a file's ownership between real and effective uid's, > >this wouldn't be a problem. Since a process can always cp a file, at > >which time it will be owned by whichever ID was active at the time, I > >don't see why that can't be allowed. > Yes, and this is a much better solution - restrict chown() to be between > the real and effective UIDs, rather that completely out the window. Right. Now we just have to convince Berkeley. > However, in a co-operative environment (such as commercial installations) > there is quite a bit of file-sharing going on in a very ad hoc fashion. I prefer the control you get from a setuid program. ---Dan
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (12/10/90)
Apart from the many detailed differences between System V (Release 3) and 4.xBSD, there is a fundamental difference in philosophy that some of you may be missing. The design of System V assumes a small, isolated system system with few users and any networking limited to UUCP. The design of BSD assumes a bigger system with many users and connectivity between machines using (usually) TCP/IP on high-speed links. On the sort of small, isolated system for which System V is designed, the ability to chown files away without restriction, and the absence of any disk quota or inode quota mechanism, does not cause a serious problem. However, consider a UNIX system with 1,000 or more users. In the absence of reasonable resource quotas, the administrator would have time to do little else but track down culprits involved in deliberate or accidental denial-of-service incidents. Hence the greater restrictions such as a restricted chown, as well as more powerful and flexible access control mechanisms such as disk quotas, multiple group memberships, and soft and hard limits on memory and CPU usage. Those of you who use only BSD-derived systems shouldn't try too hard to understand the System V user's point of view -- it will be quite strange to you, almost like trying to understand the unusual practices of a foreign country. Similarly, those of you who use only System V- derived systems should be prepared to accept what BSD users say without understanding just why they say it. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
karish@mindcraft.com (Chuck Karish) (12/10/90)
In article <18796@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >However, in a co-operative environment (such as commercial installations) >there is quite a bit of file-sharing going on in a very ad hoc fashion. That's why Berkeley systems support supplementary groups. File sharing is supported in a manageable fashion. >User's should not be forced to contact an administrator, or perform file >access mode mumbo-jumbo to give a file away. This surprises me a little. I'd thought that the most militant computer freedom zealots were BSD types. Anyway, changing a file's ownership isn't necessary for sharing. Changing its ownership handicaps the previous owner's access just as it enhances the new owner's access. Group access is the right way to share files. This is implemented in a reasonable way in BSD systems, but the POSIX.1/FIPS 151-1 translation is flawed, as I've pointed out here before. >Why FIPS went with chown() being restricted is a mystery ... Hint: FIPS 151-1 also requires that NGROUPS_MAX be non-zero. -- Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000
rickert@mp.cs.niu.edu (Neil Rickert) (12/10/90)
In article <2800:Dec1001:29:4890@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >Exactly. This is why several people have been arguing for chown() to >work between current and effective uids. Does chown() have any other >reasonable use? > A great idea. Just look at the flexibility it will provide creators of trojan horse programs. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
iand@labtam.labtam.oz (Ian Donaldson) (12/11/90)
johnl@iecc.cambridge.ma.us (John R. Levine) writes: >Does anyone really do quota accounting by the UID of the file? Consider >the following scenario: User A creates a large file. User B links to it. >User A then deletes the original link. If you charge by uid, user A is >charged for the file even though she has no control over it any more, and >might not even be able to see that it exists, depending on B's directory >protections. This is a silly argument. For user B to write to the file, he must have been granted permission by user A. Thus it is user A's responsibility in the first place that the subsequent space charging is against him. If user A wants to prevent others writing his files, thats easy. User A can also prevent people linking to his files by hiding them below a directory that has the appropriate permissions. Ian D
adeboer@gjetor.geac.COM (Anthony DeBoer) (12/11/90)
In article <18792@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >The context of the thread was that chown() messes up the quota mechanism, >and is therefore evil. Just for my $0.02 worth, if quotas are in effect, why not have a nightly daemon that goes through each user's directory and blows away anything he/she doesn't own? This should take care of out-chowning files to bypass allocation. The script would look something like: cd /u/users for USER in * do find $USER ! -user $USER -exec rm -rf {} \; done Provided that there aren't any public directories people can stash stuff into (ie. keep a handle on /tmp, /usr/spool/uucppublic, mail, etc., like you should be doing anyway), this should ensure that the number of blocks of stuff the user has equals what you see when you "du" their directory. The only other case involved would be other users sending files ("Can you give me a copy of XXXX?"), but if user A trusts user B (and anyone else in sight) enough to allow them to copy files into his/her directory, it would be reasonable to expect either user B to chown the copy of the file or for user A to copy it (to their own ownership) immediately after. And it would be more reasonable for user B to make the file readable and let user A do the actual copy anyway. -- Anthony DeBoer - NAUI #Z8800 adeboer@gjetor.geac.com Programmer, GEAC J&E Systems Ltd. uunet!jtsv16!geac!gjetor!adeboer Toronto, Ontario, Canada #include <std.random.opinions.disclaimer>
jfh@rpp386.cactus.org (John F Haugh II) (12/11/90)
In article <660809780.21869@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes: >In article <18796@rpp386.cactus.org> jfh@rpp386.cactus.org >>User's should not be forced to contact an administrator, or perform file >>access mode mumbo-jumbo to give a file away. > >This surprises me a little. I'd thought that the most militant >computer freedom zealots were BSD types. Having spent several years as the senior staff person on large business systems has mellowed certain aspects of my computer personality ;-) The statement really does come from years of experience with users asking how to give away [ or take back ;-( ] files. >Anyway, changing a file's ownership isn't necessary for sharing. >Changing its ownership handicaps the previous owner's access just >as it enhances the new owner's access. Group access is the >right way to share files. This is implemented in a reasonable >way in BSD systems, but the POSIX.1/FIPS 151-1 translation is >flawed, as I've pointed out here before. In a sense you are correct - really "sharing" a file does not require giving the file away, but from a practical standpoint you are still wrong. For =well behaved= applications concurrent group sets do help out, but many applications are not careful with how they create new files, etc. As a user who is "sharing" his files, if I set my umask to 027 (which it often is), I've just made sure I'm "read-only" sharing my files in most cases. And in practice, this is exactly what happens when dozens of non-UNIX literate users start messing around with UNIX commands. >>Why FIPS went with chown() being restricted is a mystery ... > >Hint: FIPS 151-1 also requires that NGROUPS_MAX be non-zero. Well, Doug Steves (of POSIX 1003.6 & IBM fame) and I joked around about concurrent user sets. Personally, I like that idea much better ;-) -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org
hansen@pegasus.att.com (Tony L. Hansen) (12/11/90)
< Exactly. This is why several people have been arguing for chown() to < work between current and effective uids. Does chown() have any other < reasonable use? The mail(1) command uses chown(2) and set-gid to give a secure mail system. I feel that other methods are fraught with potential security holes. Tony Hansen att!pegasus!hansen, attmail!tony hansen@pegasus.att.com
tchrist@convex.COM (Tom Christiansen) (12/11/90)
In article <1990Dec11.005644.20688@cbnewsk.att.com> hansen@pegasus.att.com (Tony L. Hansen) writes: >The mail(1) command uses chown(2) and set-gid to give a secure mail system. I >feel that other methods are fraught with potential security holes. It doesn't on a BSD system, and you're right, this has been the source of many security holes. Whether we've finally solved them all or not is unknown. --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "With a kernel dive, all things are possible, but it sure makes it hard to look at yourself in the mirror the next morning." -me
sef@kithrup.COM (Sean Eric Fagan) (12/11/90)
In article <660602312.10476@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes: >That's why FIPS 151-1 mandates that the POSIX.1 _POSIX_CHOWN_RESTRICTED >option be supported. Believe it or not, this is one feature of SCO's C2 stuff that I like. It's possible to set things up such that any specific user can use chown(), or only root, or all, or any combination in betwen. It's very nice, in a way. (I can just see them extending it: a fork() priv. bit, an exec() priv. bit, a stat() priv. bit, etc... 8-)) If I had more users on kithrup, I would probably set that up (depending on the users; for a generic, dial-up thing, yeah; if it were just friends of mine, then, no, I guess not). -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
sef@kithrup.COM (Sean Eric Fagan) (12/11/90)
In article <3128:Dec1001:47:0490@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >> However, in a co-operative environment (such as commercial installations) >> there is quite a bit of file-sharing going on in a very ad hoc fashion. >I prefer the control you get from a setuid program. I prefer the control you get from a proper implementation of ACL's. See Elxsi's EMBOS for an example. (Normal ACL's, an extension of Unix's rwx philosophy, with users and groups; passwords for files [I forget whether different users could have different passwords; I think so], and the ability to specify that a file can only be accessed using a program from a given program list [*neat*; I couldn't think of a normal use for SUID programs under embos given that!].) Sadly, when unix goes to ACL's, I suspect I won't see something like Embos. *sigh* -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
sef@kithrup.COM (Sean Eric Fagan) (12/11/90)
In article <660809780.21869@mindcraft.com> karish@mindcraft.com (Chuck Karish) writes: >Anyway, changing a file's ownership isn't necessary for sharing. >Changing its ownership handicaps the previous owner's access just >as it enhances the new owner's access. Group access is the >right way to share files. Ok. I create a file, for the sole purpose of giving to a friend of mine, who doesn't happen to be in my group. Without making the file world-readable (which I don't want to do for various reasons), how do I let my friend read it? Given the ability to do chown(), I would just chown() the file over to him. If I thought I might want to read or write it later, I might leave it group readable/writable. Not being able to do a chown() means that, when I find a file I like in a directory I own (it happens!), I have to copy it, remove it, and then rename it back. Oh, boy. Such ease. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
sef@kithrup.COM (Sean Eric Fagan) (12/11/90)
In article <1990Dec09.043647.25826@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes: >It seems to me that the only plausible way to charge for space is to assign >charge responsibility for each directory (with the default being that a >directory is charged to the same user as its parent, so you only have to list >users' home directories) and to add up the sizes of the files in all of s >user's directory, charging 1/Nth of the blocks in an N block file, rounded up. Sounds good. I'll just put everything in /tmp. Voila, no quotas. (Since /tmp is generally owned by root, and root generally has no quotas attached.) The problem you describe with links is real, and could be a problem. Anybody see any solution around this? -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
sef@kithrup.COM (Sean Eric Fagan) (12/11/90)
In article <2789@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >However, consider a UNIX system with 1,000 or more users. You mean like Amdahls? Running UTS? A SysV derivative? >In the absence of reasonable resource quotas, the administrator would have >time to do little else but track down culprits involved in deliberate >or accidental denial-of-service incidents. Hmm. Most of the Amdahl administrators I've communicated with seemed to indicate that they had enough spare time to chat away in email. Seems as if they didn't have all of their time taken up with tracking down culprits. >Hence the greater restrictions such as a restricted chown, Why not restrict mkdir and cd, as well, to prevent the infamous while : do mkdir foo cd foo done ? And, while we're at it, why not restrict read, and write, and open, and close, and sync, and lseek, and getpid, and getuid, and geteuid, and... -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
goudreau@larrybud.rtp.dg.com (Bob Goudreau) (12/12/90)
In article <5733@labtam.labtam.oz>, iand@labtam.labtam.oz (Ian Donaldson) writes: > johnl@iecc.cambridge.ma.us (John R. Levine) writes: > >Does anyone really do quota accounting by the UID of the file? > >Consider the following scenario: User A creates a large file. > >User B links to it. User A then deletes the original link. If > >you charge by uid, user A is charged for the file even though she > >has no control over it any more, and might not even be able to see > >that it exists, depending on B's directory protections. > > This is a silly argument. For user B to write to the file, he must > have been granted permission by user A. Thus it is user A's > responsibility in the first place that the subsequent space charging > is against him. So who said anything about writing? Most of the files that I access on a daily basis are read or executed, but not written. Consider the case of user A's file above. It could be an X Windows application program (which tend to be rather large unless shared libraries are used). User B could get plenty of use out of that file without ever needing to write to it. ---------------------------------------------------------------------- Bob Goudreau +1 919 248 6231 Data General Corporation goudreau@dg-rtp.dg.com 62 Alexander Drive ...!mcnc!rti!xyzzy!goudreau Research Triangle Park, NC 27709, USA
adeboer@gjetor.geac.COM (Anthony DeBoer) (12/12/90)
In article <5733@labtam.labtam.oz> iand@labtam.labtam.oz (Ian Donaldson) writes: > >johnl@iecc.cambridge.ma.us (John R. Levine) writes: >>Does anyone really do quota accounting by the UID of the file? Consider >>the following scenario: User A creates a large file. User B links to it. >>User A then deletes the original link. If you charge by uid, user A is >>charged for the file even though she has no control over it any more, and >>might not even be able to see that it exists, depending on B's directory >>protections. > >This is a silly argument. For user B to write to the file, he must >have been granted permission by user A. Thus it is user A's responsibility >in the first place that the subsequent space charging is against him. Who says user B can or needs to be able to write to the file? All they need is to be able to read the file in A's directory, write permission to their own directory, and for both to be on the same disk partition. These are sufficient permissions to let them link the file into their own directory. Now user A deletes the file, but it doesn't go away because of the second link. In fact, if B has protected that directory against other users (chmod 700 dirname), user A can't even see where the second link is (note, though, that if A is on the ball, she might see two links on an ls -l and truncate the file to zero bytes before removing it). Even if all user B can do with the file is look at it, or maybe hopefully eventually blow it away, if you do quota accounting by user the file still gets charged against A. >If user A wants to prevent others writing his files, thats easy. >User A can also prevent people linking to his files by hiding them >below a directory that has the appropriate permissions. Permissions to prevent anyone writing in your directory are reasonable and IMHO something that should be done. Preventing reading can be reasonable too if the file is sensitive, but such paranoia should not be required just because of the way a silly quota system is implemented. -- Anthony DeBoer - NAUI #Z8800 adeboer@gjetor.geac.com Programmer, GEAC J&E Systems Ltd. uunet!jtsv16!geac!gjetor!adeboer Toronto, Ontario, Canada #include <std.random.opinions.disclaimer>
les@chinet.chi.il.us (Leslie Mikesell) (12/12/90)
In article <1990Dec11.005644.20688@cbnewsk.att.com> hansen@pegasus.att.com (Tony L. Hansen) writes: >< Exactly. This is why several people have been arguing for chown() to >< work between current and effective uids. Does chown() have any other >< reasonable use? > >The mail(1) command uses chown(2) and set-gid to give a secure mail system. I >feel that other methods are fraught with potential security holes. > > Tony Hansen > att!pegasus!hansen, attmail!tony > hansen@pegasus.att.com Are you talking about the same SysV /bin/mail that I have (AT&T SysVr3) that uses the environment variable LOGNAME to decide who you are and allows you to forward your mail with the command: mail -F new_address If you are, try: MAIL=/usr/mail/you LOGNAME=you mail -F me (replace "you" with someone else on the system who happens to have an empty mailbox, and "me" with your login name) Then tell me if you would still describe the system as secure. Les Mikesell les@chinet.chi.il.us
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (12/12/90)
In <1990Dec11.103057.11204@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >Why not restrict mkdir and cd, as well, to prevent the infamous [loop that does] > mkdir foo > cd foo This problem is already handled by inode quotas. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/12/90)
In article <1990Dec10.143716.26999@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > In article <2800:Dec1001:29:4890@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >Exactly. This is why several people have been arguing for chown() to > >work between current and effective uids. Does chown() have any other > >reasonable use? > A great idea. Just look at the flexibility it will provide creators of > trojan horse programs. That's a silly objection. It won't provide any extra flexibility, since a program with access to another uid can always find every link to a file, read the data, remove the links, and put in new links to a new file under the other uid with the same data. The only time this doesn't work is when the parent directory is not owned by either uid, but what's the difference between ``vee haff destroyed zee enemy'' and ``vee haff utterly destroyed zee enemy''? Trojan Horses are deadly in any case. chown() between uid and euid will improve security for lots of system programs without introducing any noticeable security holes. ---Dan
jfc@athena.mit.edu (John F Carr) (12/12/90)
In article <1990Dec10.231812.23634@gjetor.geac.COM> adeboer@gjetor.geac.COM (Anthony DeBoer) writes: >Just for my $0.02 worth, if quotas are in effect, why not have a nightly >daemon that goes through each user's directory and blows away anything he/she >doesn't own? This should take care of out-chowning files to bypass >allocation. It is much more polite to chown the files to the owner of the directory, going up as many levels as needed to find an acceptable owner. I wrote such a program to run on our file servers (we run BSD, which doesn't allow users to run chown, but our NFS servers map unauthenticated users to user "nobody" on the server so files owned by "nobody" were accumulating in world-writeable directories). -- John Carr (jfc@athena.mit.edu)
shore@mtxinu.COM (Melinda Shore) (12/12/90)
In article <1990Dec10.231812.23634@gjetor.geac.COM> adeboer@gjetor.geac.COM (Anthony DeBoer) writes: >Just for my $0.02 worth, if quotas are in effect, why not have a nightly >daemon that goes through each user's directory and blows away anything he/she >doesn't own? Because it is Evil to mess with your users' data. Also, that's a sort of post-problem fix; the issue is really whether or not it should be allowable to give users files without giving them the option of rejecting them at the time. Writing secure setuid programs is difficult but possible, while non-root chown() takes away a user's control over his/ her own use of resources. -- Hardware brevis, software longa Melinda Shore shore@mtxinu.com mt Xinu ..!uunet!mtxinu.com!shore
dag@fciva.FRANKLIN.COM (Daniel A. Graifer) (12/12/90)
In article <1990Dec11.101909.10851@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > >I prefer the control you get from a proper implementation of ACL's. See >Elxsi's EMBOS for an example. (Normal ACL's, an extension of Unix's rwx >philosophy, with users and groups; passwords for files [I forget whether >different users could have different passwords; I think so], and the ability >to specify that a file can only be accessed using a program from a given >program list [*neat*; I couldn't think of a normal use for SUID programs >under embos given that!].) It's been awhile, but at least in the late '70s, the Burroughs large systems (Now unisys A-series) files had a 'security' attribute (amoung many other attributes such as 'filekind', sort of like unix's filename .suffix conventions, but more universal) which could be 'PRIVATE', 'CLASSA' (ie public) or 'CLASSB'. If a file was security=CLASSB, then another attribute specified the name of a GUARDFILE, which specified which user /program combinations could have what kind of access under what circumstances. There was a whole structured language for specifying this, and a guardfile compiler to translate this into efficient guardfiles. There wasn't much you couldn't do with it. In particular note the efficiency of pointing many file's guardfile attributes at the same guardfile. The guardfiles could themselves be protected by other guardfiles. This is off the subject of unix internals, but Burroughs had a lot of the elements in place for an 'object-oriented' file system clear back in the early '70s. If we're going to talk about where we'd like unix to go, there are previous successful experiances to guide us. Dan ---
ske@pkmab.se (Kristoffer Eriksson) (12/13/90)
In article <1990Dec11.102433.10999@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >In article <1990Dec09.043647.25826@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes: >>charge responsibility for each directory (with the default being that a > >Sounds good. I'll just put everything in /tmp. How would that be a problem? /tmp is usually being wiped clean now and then, so you can't store anything there which you want to keep. I have almost the same reply to the argument that if chown is free, you could make others own your files and escape quotas: if you let someone else own your file, you run the risk of that other person doing some not so nice things to your data (in fact, you deserve to loose it), so you can't use that method for any serious business. -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske
karish@mindcraft.com (Chuck Karish) (12/13/90)
In article <1990Dec11.102225.10925@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >In article <660809780.21869@mindcraft.com> karish@mindcraft.com >(Chuck Karish) writes: >>Group access is the right way to share files. >Ok. I create a file, for the sole purpose of giving to a friend of mine, who >doesn't happen to be in my group. Without making the file world-readable >(which I don't want to do for various reasons), how do I let my friend read >it? You have your system administrator make you and your friend members of the same supplementary group. Or you mail the file. -- Chuck Karish karish@mindcraft.com Mindcraft, Inc. (415) 323-9000
guy@auspex.auspex.com (Guy Harris) (12/13/90)
>The wide-open chown(2) call rampant at Death Star sites
Except those running S5R4 with wide-open "chown()" turned off; when last
I saw the code, it was a configuration option (which is nice, given that
S5R4's UFS also supports quotas...).dsmythe@netcom.UUCP (Dave Smythe) (12/13/90)
In article <1990Dec12.052114.2694@athena.mit.edu> jfc@athena.mit.edu (John F Carr) writes: >In article <1990Dec10.231812.23634@gjetor.geac.COM> > adeboer@gjetor.geac.COM (Anthony DeBoer) writes: > >>Just for my $0.02 worth, if quotas are in effect, why not have a nightly >>daemon that goes through each user's directory and blows away anything he/she >>doesn't own? This should take care of out-chowning files to bypass >>allocation. > >It is much more polite to chown the files to the owner of the directory, Suppose there are multiple links to the file; who gets to own it? The last person visited by your chown'ing utility? Or do you only chown files with only a single link? D -- Dave Smythe netcom!dsmythe@apple.com N6XLP (also dsmythe@portia.stanford.edu)
edp367s@monu6.cc.monash.edu.au (Rik Harris) (12/13/90)
dag@fciva.FRANKLIN.COM (Daniel A. Graifer) writes: >In article <1990Dec11.101909.10851@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >> >>I prefer the control you get from a proper implementation of ACL's. See >>Elxsi's EMBOS for an example. (Normal ACL's, an extension of Unix's rwx >>philosophy, with users and groups; passwords for files [I forget whether >>different users could have different passwords; I think so], and the ability >>to specify that a file can only be accessed using a program from a given >>program list [*neat*; I couldn't think of a normal use for SUID programs >>under embos given that!].) [guardfile stuff deleted] >This is off the subject of unix internals, but Burroughs had a lot of the >elements in place for an 'object-oriented' file system clear back in the >early '70s. If we're going to talk about where we'd like unix to go, there >are previous successful experiances to guide us. Eeek! The reason I love unix so much is because it's simple. Start adding security `features' like this, and things start getting complex. ACL's are nice, but generally groups are sufficient (given a good group managment system, though). Rik. -- Rik Harris - edp367s@monu6.cc.monash.edu.au | Build a system that new address! rik@sola.fcit.monash.edu.au | even a fool can use, Faculty of Computing and Information Technology, | and only a fool will Monash University, Caulfield Campus, Australia | want to use it.
edp367s@monu6.cc.monash.edu.au (Rik Harris) (12/13/90)
karish@mindcraft.com (Chuck Karish) writes: >In article <1990Dec11.102225.10925@kithrup.COM> sef@kithrup.COM >(Sean Eric Fagan) writes: >>In article <660809780.21869@mindcraft.com> karish@mindcraft.com >>(Chuck Karish) writes: >>>Group access is the right way to share files. >>Ok. I create a file, for the sole purpose of giving to a friend of mine, who >>doesn't happen to be in my group. Without making the file world-readable >>(which I don't want to do for various reasons), how do I let my friend read >>it? >You have your system administrator make you and your friend members >of the same supplementary group. Or you mail the file. We use a program called `sendfile' but that's part of the ACSnet distribution, and I guess not many of the people in the .com domain would be using the Australian Computer Science software :-) > Chuck Karish karish@mindcraft.com Rik. -- Rik Harris - edp367s@monu6.cc.monash.edu.au | Build a system that new address! rik@sola.fcit.monash.edu.au | even a fool can use, Faculty of Computing and Information Technology, | and only a fool will Monash University, Caulfield Campus, Australia | want to use it.
hansen@pegasus.att.com (Tony L. Hansen) (12/14/90)
< Les Mikesell les@chinet.chi.il.us < Are you talking about the same SysV /bin/mail that I have (AT&T SysVr3) < that uses the environment variable LOGNAME to decide who you are and < allows you to forward your mail with the command: mail -F new_address < If you are, try: < MAIL=/usr/mail/you LOGNAME=you mail -F me < (replace "you" with someone else on the system who happens to have an < empty mailbox, and "me" with your login name) < Then tell me if you would still describe the system as secure. Yes, that bug was once there, but has been since squashed in SVr4 mail. Compare the small number of security problems in Sys V mail through the years (always using setgid+chown) with the numerous security problems in BSD mail through the years (using setuid-root, world-writable mail area, or various other schemes). I'll take the setgid+chown any day. Tony Hansen att!pegasus!hansen, attmail!tony hansen@pegasus.att.com
les@chinet.chi.il.us (Leslie Mikesell) (12/14/90)
In article <1990Dec11.102225.10925@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >Ok. I create a file, for the sole purpose of giving to a friend of mine, who >doesn't happen to be in my group. Without making the file world-readable >(which I don't want to do for various reasons), how do I let my friend read >it? Encrypt it and give him the key. Or mail it. >Not being able to do a chown() means that, when I find a file I like in a >directory I own (it happens!), I have to copy it, remove it, and then rename >it back. Oh, boy. Such ease. It also means that you know who put there (you or root). Les Mikesell les@chinet.chi.il.us
ray@ctbilbo.UUCP (Ray Ward) (12/14/90)
In article <110091@convex.convex.com>, tchrist@convex.COM (Tom Christiansen) writes: > Yes, but what happens where chown is not privileged? > > % mkdir foo > % touch foo/bar > % chown somebody_else foo/bar foo > > Now how do I get rid of that stuff? There seems to be a theme ( sub-thread? fiber? ) on this thread that if you can do something to a file that you can't undo without superuser permissions, it is inherently bad, un-UNIX, Death-Star chic, or whatnot. I disagree. Consider the following: % rm -f foo/bar Try getting the superuser to recover the file, on most systems. It is possible to *actually* do things: permanent, irrecoverable, or other definite types of things. Even stupid or inconvenient things. I have always considered this to be one of the beauties of UNIX: it assumes you know what you're doing, whether you do or not. The software is assumed to work: it doesn't run off at the mouth telling you, "I made it this far, so far, so good!" unless you ask it to. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ray Ward Email: uunet!ctbilbo!ray Voice: (214) 991-8338x226, (800) 331-7032 Fax : (214) 991-8968 =-=-=-=- There _are_ simple answers, just no _easy_ ones. -- R.R. -=-=-=-=
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (12/14/90)
In <1990Dec13.192712.25225@cbnewsk.att.com> hansen@pegasus.att.com (Tony L. Hansen) writes: >...the numerous security problems in BSD mail >through the years (using setuid-root, world-writable mail area, or various >other schemes) Is there a security problem if the mail spool directory is world- writable but its sticky bit is set? -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
darcy@druid.uucp (D'Arcy J.M. Cain) (12/14/90)
In article <1990Dec13.155645.10478@monu6.cc.monash.edu.au> Rik Harris writes: >karish@mindcraft.com (Chuck Karish) writes: >>>>Group access is the right way to share files. >>>Ok. I create a file, for the sole purpose of giving to a friend of mine, who >>>doesn't happen to be in my group. Without making the file world-readable >>You have your system administrator make you and your friend members >>of the same supplementary group. Or you mail the file. >We use a program called `sendfile' but that's part of the ACSnet Why not use uuto? I do it all the time for that sort of thing. E.G: uuto -p myfile !user I always use the -p option so I don't have to figure out if I am in a directory readable by uucp. Note the bang in front of user. -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | There's no government West Hill, Ontario, Canada | like no government! +1 416 281 6094 |
rickert@mp.cs.niu.edu (Neil Rickert) (12/14/90)
In article <2803@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > >Is there a security problem if the mail spool directory is world- >writable but its sticky bit is set? cd /usr/spool/mail ls dhesi Error: dhesi not found touch dhesi chmod 777 dhesi Now I own your mail box. Depending on the version of /bin/mail the ownership may revert to you when you next receive mail. But it is publically readable. Maybe you go around checking if your mailbox is publically readable, but most people don't. (This is not to mentions some other problems which I would prefer not to publicize). -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
jfh@rpp386.cactus.org (John F Haugh II) (12/15/90)
In article <1990Dec13.204819.17846@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1990Dec11.102225.10925@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >>Ok. I create a file, for the sole purpose of giving to a friend of mine, who >>doesn't happen to be in my group. Without making the file world-readable >>(which I don't want to do for various reasons), how do I let my friend read >>it? > >Encrypt it and give him the key. Or mail it. All you are doing is proving the point that root-only chown() makes for an administrative nightmare. Nowhere on the crypt manpage does it mention that crypt can be used to change the ownership of a file. Mail is pretty much the same story, with the added complexity of dealing with binary files. If you really want to have a chown that protects the recipient, have chown ask for the recipient's password. Authenticate the luser and then do the chown. Now the chown command can be used to chown files, and you don't have to use crypt/mail/uuencode/etc. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "While you are here, your wives and girlfriends are dating handsome American movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."
woods@eci386.uucp (Greg A. Woods) (12/15/90)
In article <1990Dec11.203632.7402@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > In article <1990Dec11.005644.20688@cbnewsk.att.com> hansen@pegasus.att.com (Tony L. Hansen) writes: > >The mail(1) command uses chown(2) and set-gid to give a secure mail system. I > >feel that other methods are fraught with potential security holes. > > Are you talking about the same SysV /bin/mail that I have (AT&T SysVr3) > that uses the environment variable LOGNAME to decide who you are > and allows you to forward your mail with the command: > mail -F new_address > > If you are, try: > MAIL=/usr/mail/you LOGNAME=you mail -F me > (replace "you" with someone else on the system who happens to have an > empty mailbox, and "me" with your login name) > > Then tell me if you would still describe the system as secure. $ uname -a eci386 eci386 1.0.6 1 80386 $ # [That's 386/ix, an AT&T System V Release 3.0 derivative] $ ls -l /usr/mail/chris -rw-rw---- 1 chris mail 0 Nov 4 12:59 /usr/mail/chris $ # [binmail is the real mail, mail is svbinmail from smail-2.5] $ ls -l /bin/binmail -rwxr-sr-x 2 bin mail 49208 Jun 2 1988 /bin/binmail $ what /bin/binmail /bin/binmail: cb:mail 386/ix Version 1.0.6 $ MAIL=/usr/mail/chris LOGNAME=chris /bin/binmail -F woods binmail: Invalid permissions binmail: Cannot install/remove forwarding without empty mailfile $ ls -l /usr/mail/chris -rw-rw---- 1 chris mail 0 Nov 4 12:59 /usr/mail/chris $ ls -l /usr/mail/root -rw-rw---- 1 root mail 27820 Dec 12 05:18 /usr/mail/root $ MAIL=/usr/mail/root LOGNAME=root /bin/binmail -F woods binmail: Invalid permissions binmail: Cannot install/remove forwarding without empty mailfile $ Hmm... Yup, it seems secure to me! Doesn't mean non-superuser chown is OK, but IMHO it *is* not only OK, but useful! -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
les@chinet.chi.il.us (Leslie Mikesell) (12/15/90)
In article <1990Dec13.192712.25225@cbnewsk.att.com> hansen@pegasus.att.com (Tony L. Hansen) writes: >< Are you talking about the same SysV /bin/mail that I have (AT&T SysVr3) >Yes, that bug was once there, but has been since squashed in SVr4 mail. >Compare the small number of security problems in Sys V mail through the years >(always using setgid+chown) with the numerous security problems in BSD mail >through the years (using setuid-root, world-writable mail area, or various >other schemes). I'll take the setgid+chown any day. But those problems mostly relate to the additional functionality of those other mailers. SysV mail doesn't (and can't without being setuid root) offer to run pipes in my .forward file under my uid during delivery. It also happily takes my word that I am who I say I am. The "enhanced" /bin/mail that is supplied with AT&T's PMX-mailer products introduces a crude way of specifying programs as aliases and thus incurrs some new security problems. I suppose this is also "fixed in SysVr4" by disallowing any shell metacharacters in mail addresses. I fixed it by installing smail 3 and tossing the AT&T stuff, although it has some problems as well. In particular, its security checking is severely compromised by the /bin/mail behaviour I mentioned earlier and the fact that a setuid program can't determine (at least under sysV) the effective id of the invoker. But at least now if I find a problem I can fix it. Les Mikesell les@chinet.chi.il.us
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (12/16/90)
In <1990Dec14.150710.4273@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > cd /usr/spool/mail > touch dhesi > chmod 777 dhesi > Now I own your mail box. I believe this problem was fixed going from 4.2BSD to 4.3BSD; if I remember correctly, the mail delivery program forces the mailbox to be owned by the user and not readable or writable by anybody else. If it doesn't, or if I'm remembering incorrectly, the security problem is in the mail delivery program, *not* with the fact that the mail directory itself is world-writable. We are assuming, of course, that the sticky bit is set on the mail directory. When there is a security problem caused by the combination of two things (e.g., 1. mail directory world-writable, 2. mail delivery program doesn't force mailbox security) one can't blame a lack of security on just one of those things The main problem with keeping mail directories world-not-writable and keeping mail user agents set-gid is that it becomes harder for Joe user to install his own user agent without the cooperation of the system administrator. You should not need any sysadmin support to read your own mail. I will grant you that a denial-of-service situation is still possible by simply going to the mail directory and creating a file $USER.lock, thus fooling all other mail programs into thinking that the mailbox is locked. The solution is for the mail delivery program to either not use this locking scheme (use flock instead), or to force an unlock if the lock file is too old. Actually, if everybody used flock, then you wouldn't need to make mail user agents set-gid, because they would never have to create any new files in the mail directory. Unfortunately, even our our super modern Suns, the default mail program uses a $USER.lock file, and I wouldn't be surprised if this is true on may other UNIX derivatives. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/16/90)
As quoted from <1990Dec11.102433.10999@kithrup.COM> by sef@kithrup.COM (Sean Eric Fagan): +--------------- | In article <1990Dec09.043647.25826@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes: | >It seems to me that the only plausible way to charge for space is to assign | >charge responsibility for each directory (with the default being that a | >directory is charged to the same user as its parent, so you only have to list | >users' home directories) and to add up the sizes of the files in all of s | >user's directory, charging 1/Nth of the blocks in an N block file, rounded up. | | Sounds good. I'll just put everything in /tmp. +--------------- I assume the semantics of a sticky directory would be expanded to cover this, thus catching tmp files and mailboxes.... ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
rickert@mp.cs.niu.edu (Neil Rickert) (12/16/90)
In article <2807@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: >In <1990Dec14.150710.4273@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil >Rickert) writes: > >> cd /usr/spool/mail >> touch dhesi >> chmod 777 dhesi > >> Now I own your mail box. > >I believe this problem was fixed going from 4.2BSD to 4.3BSD; if >I remember correctly, the mail delivery program forces the mailbox >to be owned by the user and not readable or writable by anybody else. I believe you will find that it does not change the permissions. Note the chmod I listed there, so that even if owner and group are changed by /bin/mail the mailbox is still public. Of course you can make it private again. But how many people go around regularly checking the permissions on their mailbox? The /bin/mail on a Sun 4.1 does not seem to change mailbox ownership. I have a guest account on such a system in which the admin changed my uid, and the result was I could not access my mailbox till I got him to fix the ownership. >If it doesn't, or if I'm remembering incorrectly, the security problem >is in the mail delivery program, *not* with the fact that the mail >directory itself is world-writable. We are assuming, of course, that >the sticky bit is set on the mail directory. > >I will grant you that a denial-of-service situation is still possible >by simply going to the mail directory and creating a file $USER.lock, Don't you consider this a problem? -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/16/90)
As quoted from <1990Dec11.203632.7402@chinet.chi.il.us> by les@chinet.chi.il.us (Leslie Mikesell): +--------------- | In article <1990Dec11.005644.20688@cbnewsk.att.com> hansen@pegasus.att.com (Tony L. Hansen) writes: | >The mail(1) command uses chown(2) and set-gid to give a secure mail system. I | >feel that other methods are fraught with potential security holes. | | MAIL=/usr/mail/you LOGNAME=you mail -F me +--------------- LOGNAME was used to (a) get your mail even while you're su'd and (b) get around the fact that more than one login name can map to a given uid. (Note to SCO: luids do *not* fix this, so don't get any stupid ideas.) My guess is that it should use LOGNAME only if its associated uid is the same as the real uid (or luid, if available; arguably, one wants to read one's own mail from under su in most cases). I agree: setgid /bin/mail was a very good idea with only that one fatal flaw. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (12/16/90)
As quoted from <18687@netcom.UUCP> by dsmythe@netcom.UUCP (Dave Smythe): +--------------- | In article <1990Dec12.052114.2694@athena.mit.edu> jfc@athena.mit.edu (John F Carr) writes: | >In article <1990Dec10.231812.23634@gjetor.geac.COM> | > adeboer@gjetor.geac.COM (Anthony DeBoer) writes: | > | >>Just for my $0.02 worth, if quotas are in effect, why not have a nightly | >>daemon that goes through each user's directory and blows away anything he/she | >>doesn't own? This should take care of out-chowning files to bypass | >>allocation. | > | >It is much more polite to chown the files to the owner of the directory, | | Suppose there are multiple links to the file; who gets to own it? The last | person visited by your chown'ing utility? Or do you only chown files with | only a single link? +--------------- The other problem is that the sysadmin is going to be in big trouble when I come in the next day and discover that my latest development copy of qzt (which is setuid uucp) has been blown away or un-permissioned.... Admitted, group vectors are nice, but I'd need an infinitely sized group vector to cover all the possibilities, so some things are still setuid instead of setgid. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
les@chinet.chi.il.us (Leslie Mikesell) (12/17/90)
In article <1990Dec14.171022.4992@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: >$ ls -l /usr/mail/root >-rw-rw---- 1 root mail 27820 Dec 12 05:18 /usr/mail/root >$ MAIL=/usr/mail/root LOGNAME=root /bin/binmail -F woods >binmail: Invalid permissions >binmail: Cannot install/remove forwarding without empty mailfile >Hmm... Yup, it seems secure to me! Doesn't mean non-superuser chown >is OK, but IMHO it *is* not only OK, but useful! Oops, when I said empty file I meant no file (my mail reader always deletes the file when it is empty). Does your mail reader always leave a 0 length file in /usr/mail when you delete all the messages? Does everyone on the system use the same reader (or do they all do this)? Is there ever a time when a user does not have a file in /usr/mail (say before they have ever received any mail)? IMHO it would be just as useful if it didn't chown the forwarding file but left it owned by the uid that actually gave the command. Les Mikesell les@chinet.chi.il.us
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/17/90)
In article <2803@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > In <1990Dec13.192712.25225@cbnewsk.att.com> hansen@pegasus.att.com > (Tony L. Hansen) writes: > >...the numerous security problems in BSD mail > >through the years (using setuid-root, world-writable mail area, or various > >other schemes) > Is there a security problem if the mail spool directory is world- > writable but its sticky bit is set? Yes. On some systems, for instance, you can keep someone from reading mail by touching /usr/spool/mail/victim.lock. On others you can create mailboxes for new users. ---Dan
les@chinet.chi.il.us (Leslie Mikesell) (12/17/90)
In article <18821@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >>Encrypt it and give him the key. Or mail it. >All you are doing is proving the point that root-only chown() makes >for an administrative nightmare. Nowhere on the crypt manpage does >it mention that crypt can be used to change the ownership of a file. Encryption provides the advantage of also protecting you from casual browsing by the administrator while allowing ownership to be changed the "right" way (i.e. by leaving the file readable so that the new owner can make his own copy). >Mail is pretty much the same story, with the added complexity of >dealing with binary files. Yes, of course mail should be fixed allow attachments. Mine is, using a combination of AT&T's PMX mail UA's and smail 3.1. My users generally don't know (or need to know) who is on the same machine with them. All they need is the mail alias to share files. End of problem. >If you really want to have a chown that protects the recipient, have >chown ask for the recipient's password. Authenticate the luser and >then do the chown. Now the chown command can be used to chown files, >and you don't have to use crypt/mail/uuencode/etc. Umm, we've already got that under the guise of "su". And, this would require you to know someone's password to send them mail if your mailer runs setgid instead of setuid root. The main thing that I object to about chown is that it prevents sensible security checks from working that could otherwise help setuid root programs decide who created a file. For example, a mailer wanting to execute a pipe in a .forward file might be able to tell who created that file. As things are, it has to check the directory for write permission (and hope those permissions applied when the file was created) and can be fooled by other programs that use special permissions to create files that look like they belong to you. Maybe requiring the setuid bit to be set on these files would work, though, since chown is supposed to clear that. Les Mikesell les@chinet.chi.il.us
greywolf@unisoft.UUCP (The Grey Wolf) (12/22/90)
In article <18821@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: >In article <1990Dec13.204819.17846@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >>In article <1990Dec11.102225.10925@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >>>Ok. I create a file, for the sole purpose of giving to a friend of mine, who >>>doesn't happen to be in my group. Without making the file world-readable >>>(which I don't want to do for various reasons), how do I let my friend read >>>it? >> >>Encrypt it and give him the key. Or mail it. > >All you are doing is proving the point that root-only chown() makes >for an administrative nightmare. Nowhere on the crypt manpage does >it mention that crypt can be used to change the ownership of a file. >Mail is pretty much the same story, with the added complexity of >dealing with binary files. My only complaint about this is that John, you are throwing in a red herring here by mentioning chown() and crypt() in the same breath. The only thing that Les was suggesting was an alternative to chown. Here, where we don't have a problem with giving files away (and we are fortunate enough to have source (which, I understand, unfortunately, most people don't -- sighhhh)), I just "#ifdef QUOTA"d around the suser() check. If you don't have source, a moderately skilled programmer with the knowledge of the assembly code of the machine he's working on (no big feat) should be able to patch the routine in the kernel such that the jump to suser() becomes a string of no-ops. Not optimal, but it works. The rest of the restrictions, such as the clearing of the setuid and setgid bits unless you're the superuser, and the fact that you can't re-acquire a file unless you're the superuser, are already in place. > >If you really want to have a chown that protects the recipient, have >chown ask for the recipient's password. Authenticate the luser and >then do the chown. Now the chown command can be used to chown files, >and you don't have to use crypt/mail/uuencode/etc. This is great. Except in an environment where quotas are enabled (such as a university). I've seen too many instances where a student drops or forgets to change his/her passwd from the default (SSN), and another student (likely a group of students) finds (guesses) the password and starts using that account. Even when the account goes away, there will be scattered files which belong to someone else who can no longer be accounted for. Yeah, I know, "so use 'find fs -nouser ...'". The thing is that this headache should not ever exist in the first place. In small universities, it works okay. In larger ones, the sysads usually have their hands full already. If quotas are enabled, chown() should be a privileged call. If they aren't, then chown() should be available to the world. >-- >John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh >Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org >"While you are here, your wives and girlfriends are dating handsome American > movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson." -- On the 'Net: Why are more and more fourth-level wizard(-wannabe)s trying to invoke ninth-level magic, instead of taking the time to climb the other (quite essential) thirteen levels so they can do this properly? ...!{ucbvax,acad,uunet,amdahl,pyramid}!unisoft!greywolf
adeboer@gjetor.geac.COM (Anthony DeBoer) (01/07/91)
Awhile back in this thread we were discussing what to do about files in users' directories that they didn't own; I advocated rm'ing them during nightly cleanup and got lightly flamed and somebody else said it would be better to chown them to the user. Over the weekend something filtered up from the subconscious: Suppose a user does: "ln /usr/bin/vi /usr/myself" one evening. The nightly cleanup sees a file in his account that belongs to "bin" and chowns it to him. Since the two links point to only one file, he now owns /usr/bin/vi! The following morning he replaces it with a trojan that checks if root is vi'ing a file and quickly does dirty work if so, and in either case exec's a copy of the real vi to make the change invisible to the invoker. The solution could be to alter the daemon to make the user a copy of the offending file and remove the original, but a simple chown is a serious security hole. -- Anthony DeBoer - NAUI #Z8800 adeboer@gjetor.geac.com Programmer, Geac J&E Systems Ltd. uunet!jtsv16!geac!gjetor!adeboer Toronto, Ontario, Canada #include <std.random.opinions.disclaimer>
jc@minya.UUCP (John Chambers) (01/15/91)
In article <1991Jan7.145146.7589@gjetor.geac.COM>, adeboer@gjetor.geac.COM (Anthony DeBoer) writes: > Awhile back in this thread we were discussing what to do about files in users' > directories that they didn't own; I advocated rm'ing them during nightly > cleanup and got lightly flamed and somebody else said it would be better to > chown them to the user. Well, frankly, if I ever discover such a "cleanup" script, I'll drop what I'm doing, go super-user, and eliminate the little monster. Way back when I first stumbled across Unix, one of my first reactions was "Wow, a system that actually lets users share files and work together!" Now people come along and suggest that this is a bad idea, and that users who have the gall to engage in cooperation and sharing of their work are to be punished by silently removing their shared files or by jumbling the ownership so you can't tell who was responsible for what. Really marvelous. But I guess it's to be expected in a society whose school system's general term for cooperation is "cheating". And we wonder why the USA is becoming a third-rate industrial power. -- All opinions Copyright (c) 1991 by John Chambers. Inquire for licensing at: Home: 1-617-484-6393 Work: 1-508-486-5475 Uucp: ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc
adeboer@gjetor.geac.COM (Anthony DeBoer) (01/15/91)
In article <450@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >In article <1991Jan7.145146.7589@gjetor.geac.COM>, adeboer@gjetor.geac.COM (Anthony DeBoer) writes: >> Awhile back in this thread we were discussing what to do about files in users' >> directories that they didn't own; I advocated rm'ing them during nightly >> cleanup and got lightly flamed and somebody else said it would be better to >> chown them to the user. > >Well, frankly, if I ever discover such a "cleanup" script, I'll drop what >I'm doing, go super-user, and eliminate the little monster. > >Way back when I first stumbled across Unix, one of my first reactions was >"Wow, a system that actually lets users share files and work together!" >Now people come along and suggest that this is a bad idea, and that users >who have the gall to engage in cooperation and sharing of their work are >to be punished by silently removing their shared files or by jumbling the >ownership so you can't tell who was responsible for what. The original thread concerned the problem of disk resource hogging. Apparently some systems implement quotas (my system doesn't, and I don't think I miss them) to prevent a user from taking more than x number of disk blocks. There's a loophole that if a user can chown his files to somebody else they get excluded from his quota calculation and he can exceed it. The discussion was what to do about this: change the kernal to disallow users from chown'ing, or scan for files of other ownership in their accounts and do something about them. The 'rm daemon' was suggested on the assumption that other-ownership files in a person's account were explicit instances of quota-bypassing. My system's default UMASK value is 022, which gives me full access and everyone else read-only access on my files and directories. Therefore, if a file is in my account I put it there and I'll be (or should be) the owner. If I'm going to be sharing files with others, they can find them in my directory or I'll look for them in theirs. You might want a quota system if new users are happily filling the disk every other week, but that leads straight into the whole area of openness vs. security. I'm certainly a lot happier on an open system, but you don't know who you can trust nowadays. Let your friends write a file and your enemies will eventually trash it. Or a well-meaning friend will do it inadvertently. Yesterday one of my co-workers learned a bit more about uucp and how there's a practical limit on how much data you can copy to another system at once when he filled a partition. We only lost a little bit of incoming mail, according to our neighboring sysop. On the whole, though, I'd rather be able to trust people and not have disk quotas at all. Take a look at Cliff Stoll's book, "The Cuckoo's Egg". I can agree with his attitudes. Computer users are a community, and we need to trust each other to get real work done and not have to spend all our time securing everything. If someone does violate that trust and do their worst on my system, I am prepared to take action at that point. And I'm prepared to spend time helping new users develop a positive attitude. >Really marvelous. But I guess it's to be expected in a society whose >school system's general term for cooperation is "cheating". It's not always that bad. I was assigned group projects back in college, and my only major objection was that the person in the group who knew the most usually wound up doing most of the work and the others didn't learn a lot. The problem with the educational system is they're handing out individual grades and that can logically follow to them wanting to look at each student isolated from the others. It's good experimental method and makes sense considering the general scientific mindset present in any good PhD, but it does reflect the underlying assumption of individualism rather than teamwork. But that's probably a discussion for some other newsgroup. -- Anthony DeBoer - NAUI #Z8800 adeboer@gjetor.geac.com Programmer, Geac J&E Systems Ltd. uunet!jtsv16!geac!gjetor!adeboer Toronto, Ontario, Canada #include <std.random.opinions.disclaimer>
zlsiial@uts.mcc.ac.uk (A.V. Le Blanc) (01/16/91)
There may be other reasons for mounting a quota system than lack of trust. On some of the workstations which I manage there are 150 to 200 users and fairly limited filestore. We have a simple quota system because a small number of people can fill the filestore by creating a few large files. Moreover, many of our commonly used software packages create large output files, which we must be certain are archived or transferred or analysed or otherwise processed and deleted as soon as possible. Occasionally we must suppress quota checking for one or another user, but this is better than having full disks halt the system several times a day. A. V. Le Blanc ZLSIIAL@UK.AC.MCC.CMS