grdetil@ccu.umanitoba.ca (Gilles R. Detillieux) (06/21/91)
I have been reading this group for a while, but haven't seen this question addressed: Why does the NeXT reassign ownership of all files on an Optical Disk to the user ID of the person logged in? Can this be disabled? The Optical Disk drive on our NeXT is shared by many people on our network. (Now that the OD is no longer standard equipment on NeXT, I suspect that a lot of OD drives will be shared in similar ways at other sites.) We find it extremely annoying when one user is logged into the NeXT console (usually me), and another user wants to access or update one of his disks, logging in over the network. He inserts his disk, and then all of his files now belong to me; he can't even update his own disk because he doesn't have write permission on the directories. I usually have to stop what I'm doing, log out, and let the other person log in while he updates his disk, even if he is going to do it over the network. Am I the only NeXT user to think that this is a REALLY stupid "feature" in the NeXT's Optical Disk support? Under 1.0a, at least I could open a terminal window, do an "su", and change the ownerships back to their rightful owner. The change seemed to stick. Under 2.0, it doesn't stick - even while the disk it still mounted, the ownerships I set eventually turn back to the userid at the console. If anyone has found a way to defeat this annoying "feature", could you let me know? If NeXT is listening, how about a fix for this in the next release? -- Gilles Detillieux <Gilles@scrc.UManitoba.CA> Spinal Cord Research Centre or <grdetil@ccu.UManitoba.CA> Dept. of Physiology, U. of Manitoba Phone: (204)788-6766 Winnipeg, MB R3E 0W3 (Canada) Fax: (204)786-0932
eps@toaster.SFSU.EDU (Eric P. Scott) (06/21/91)
In article <1991Jun20.220525.5015@ccu.umanitoba.ca> grdetil@ccu.umanitoba.ca (Gilles R. Detillieux) writes: >Am I the only NeXT user to think that this is a REALLY stupid "feature" in >the NeXT's Optical Disk support? It's not just in OD support. It's in all mountable media EVEN IF automount=no is set in the disk label. Funny you should mention this as the "virus" discussion is happening; this is one of the biggest weaknesses introduced in 2.x--it totally blows away normal UNIX file protections. I was really shocked when it did this with one of my Fujitsus. If you don't mount all your disks through fstab, watch out! -=EPS=-
ddj@zardoz.club.cc.cmu.edu (Doug DeJulio) (06/21/91)
In article <1991Jun20.220525.5015@ccu.umanitoba.ca> grdetil@ccu.umanitoba.ca (Gilles R. Detillieux) writes: >I have been reading this group for a while, but haven't seen this question >addressed: Why does the NeXT reassign ownership of all files on an >Optical Disk to the user ID of the person logged in? Can this be disabled? It makes sense. If you want to excange data with somone, you need to do this. If you want to use the same disk on machines that have the accounts set up differently, you need to do this. It happens not because it's an OD, but because it's a removable medium. The same thing happens with floppy disks, or with external SCSI disks that aren't normally mounted. It's the automounter's "fault". >Am I the only NeXT user to think that this is a REALLY stupid "feature" in >the NeXT's Optical Disk support? Well, I think it's a really good idea. >If anyone has found a way to defeat this annoying "feature", could you let >me know? If NeXT is listening, how about a fix for this in the next release? Bypass the automounter. Don't put the floptical in the cube. Su to root, and type "mount /dev/od0a /floptical". It'll prompt you to insert the disk. It'll then treat it like a hard drive instead of like removable media (ie. ownership won't have anything to do with who's at console, and you can chown stuff). -- Doug DeJulio ddj@zardoz.club.cc.cmu.edu
nathan@jacobi.biology.yale.edu (Nathan F. Janette) (06/22/91)
In article <1991Jun20.220525.5015@ccu.umanitoba.ca> grdetil@ccu.umanitoba.ca (Gilles R. Detillieux) writes: > I have been reading this group for a while, but haven't seen this question > addressed: Why does the NeXT reassign ownership of all files on an > Optical Disk to the user ID of the person logged in? Can this be disabled? > > The Optical Disk drive on our NeXT is shared by many people on our network. > (Now that the OD is no longer standard equipment on NeXT, I suspect that > a lot of OD drives will be shared in similar ways at other sites.) We > find it extremely annoying when one user is logged into the NeXT console > (usually me), and another user wants to access or update one of his disks, > logging in over the network. He inserts his disk, and then all of his files > now belong to me; he can't even update his own disk because he doesn't have > write permission on the directories. I usually have to stop what I'm doing, > log out, and let the other person log in while he updates his disk, even if > he is going to do it over the network. > > Am I the only NeXT user to think that this is a REALLY stupid "feature" in > the NeXT's Optical Disk support? Somebody say Amen! I posted complaining about the frustration of trying to allow non-root users to mount and use the optical drives of remote cubes several weeks ago. No one had any useful suggestions to offer... To summarize what I've learned: 1. You can't export the directory "/OpticalDisk" on a cube unless there is a disk currently mounted. 2. You can't export "/" to some machines and "/user" to others if both are in the same filesystem (as noted in the exportfs man pages). 3. You can't mount a remote filesystem as a non-root user. 4. Even if you mount the remote filesystem "/" of a cube with a loaded OD, the mount point doesn't register in your browser or from a terminal. 5. If you mount the remote filesystem "/OpticalDisk" you experience the file\ permissions trouble detailed above by Gilles R. Detillieux. As I said in my previous post, I think it is really crazy how difficult it is to use a cube OD drive to serve remote stations/cubes, especially with a system that is touted as the end-all-be-all of "Interpersonal Computing". This is quite frustrating, since we could have two loaded NeXTStations for every one NeXTCube w/OD drive we have to purchase... -- Nathan Janette nathan@jacobi.biology.yale.edu
hoodr@syscube.ccs.csus.edu (Robert Hood) (06/22/91)
In article <1991Jun20.220525.5015@ccu.umanitoba.ca> grdetil@ccu.umanitoba.ca (Gilles R. Detillieux) writes: >The Optical Disk drive on our NeXT is shared by many people on our network. >(Now that the OD is no longer standard equipment on NeXT, I suspect that >a lot of OD drives will be shared in similar ways at other sites.) We >find it extremely annoying when one user is logged into the NeXT console >(usually me), and another user wants to access or update one of his disks, >logging in over the network. He inserts his disk, and then all of his files >now belong to me; he can't even update his own disk because he doesn't have >write permission on the directories. I usually have to stop what I'm doing, >log out, and let the other person log in while he updates his disk, even if >he is going to do it over the network. Who really mounted the disk? If someone sticks in a disk while YOU are logged in at the console, the NeXT automounts the disk for YOU). The problem you are running into is actually a security feature. Hypothetical situation: (I wish) I own a NeXT. I have superuser (as well as any other user) access. I create an optical disk with a setuid root shell (or any program). I could also create a setuid shell for your user id too. I come over to the NeXT you are working on, and shove in the disk. It mounts it. It preserves the user ids. I log in remotely, and execute that setuid root shell it so nicely preserved for me. I'm superuser! I blow you off the system. I erase all your files. I erase everyones files! I go crazy! I get thrown in jail... :-) Preserving UIDs is possible, but you have to mount the disk as root. You can't use automount. You have to 'manually' mount it like this: su # become superuser mount /dev/od0a /mnt # mount the optical on /mnt and to unmount su # become superuser umount /mnt # unmount the filesystem on /mnt disk -e /dev/rod0a # Eject the disk -- Robert Hood - Operating Systems and Network Support California State University: Sacramento E-Mail: hoodr@csus.edu Phone: (916) 278-7402 Fax: (916) 278-7671
sksircar@shade.princeton.edu (Subrata Sircar) (06/22/91)
eps@cs.SFSU.EDU (Eric P. Scott) writes: >In article <1991Jun20.220525.5015@ccu.umanitoba.ca> >>Am I the only NeXT user to think that this is a REALLY stupid "feature" in >>the NeXT's Optical Disk support? > >It's not just in OD support. It's in all mountable media EVEN IF >automount=no is set in the disk label. Wait. Are you people saying that if I log in to the Next, and insert a backup optical disk (made by root) that all of the files on that disk are now owned by me? Even if the mountable media has root-owned files? If so, that's not just stupid, that's criminal. What's to prevent anyone from doing ANYTHING they want to a mountable medium, for example a source disk mounted over a network? Has anyone mailed this to Next's bug fix address, or called it in? Seems to me that totally destroys the usefulness of mounting optical disks as network server volumes ... -- Subrata Sircar | sksircar@phoenix.princeton.edu |Prophet& SPAMIT Charter Member I don't speak for Princeton, and they don't speak for me. "May their souls rot in easy-listening hell!" - Johnny Melnibone, GRIMJACK #76 "I seem to suffer from irrelevant flashbacks." - Paul, PAUL THE SAMURAI #1
eps@toaster.SFSU.EDU (Eric P. Scott) (06/22/91)
In article <1991Jun21.203134.7927@csus.edu> hoodr@syscube.ccs.csus.edu (Robert Hood) writes: >The problem you are running into is actually a security feature. How? By giving me READ and WRITE access to other people's data? Some feature. >Hypothetical situation: >(I wish) I own a NeXT. I have superuser (as well as any other user) access. >I create an optical disk with a setuid root shell (or any program). As long as the automounter sets the "nosuid" flag your argument doesn't hold. -=EPS=-
eps@toaster.SFSU.EDU (Eric P. Scott) (06/22/91)
In article <11043@idunno.Princeton.EDU> sksircar@shade.princeton.edu (Subrata Sircar) writes: >Wait. Are you people saying that if I log in to the Next, and insert a backup >optical disk (made by root) that all of the files on that disk are now owned >by me? Even if the mountable media has root-owned files? That's EXACTLY what happens. Whatever ownership was recorded on the disk is ignored on read, and any files you create as yourself will be created as if by root! All the security and convenience of MS-DOS! (Who says the NeXT can't emulate a PeeCee well?) -=EPS=-
mikec@wam.umd.edu (Michael D. Callaghan) (06/23/91)
On my machine (an 040 Cube/660/OD) I name all my Opticals /Optical. In my /etc/exports file there is a line which reads /Optical -access=daffy,root=daffy When my machine boots, it finds that there is no /Optical, and therefore does not export it. Even if I then insert a disk, the user at daffy cannot mount it, unless I first su to root, and issue an exportfs -a command. And even then, only the machine "daffy" has access to it. Since the manager of daffy is my business partner, and daffy sits five feet from my machine (bugs), we don't have a problem. Granted, we frequently run into the ownership problem, but we usually only use the Optical for archival purposes, in which case we both log in as the same user (member or operator and wheel). In short, I see how it could be a security risk. But like any risks, if you're careful, you'll probably be fine. Just keep those ODs out of strange hands. MikeC -- --------------------------------------------------------- Michael D. Callaghan, MDC Designs, University of Maryland ---------------------------------------------------------
wb1j+@andrew.cmu.edu (William M. Bumgarner) (06/24/91)
There is a very good reason for a mountable piece of media (such as OD's or floppies) to be owned by the current console user. Think about it: Say you have a root owned (or any other user owned) setuid copy of shell (or any number of other isidiously powerful programs) on a piece of removable media. Wouldn't it be rather large security hole to be able to shove that disc into ANY machine and suddenly be able to be root simply by running your set uid shell? I don't see any way to avoid this; sure, you could not allow csh or sh to be run as set uid from a piece of media, but what about any of the number of other apps that are out there that can diddle files? b.bum (w/a commentary from Dan Grillo) b.bumgarner | Disclaimer: All opinions expressed are my own. wb1j+@andrew.cmu.edu | I officially don't represent anyone unless I NeXT Campus Consultant | explicity say I am doing so. So there. <Thpppt!> "I ride tandem with the random/Things don't run the way I planned them.."
mheubi@itr.ch (Heubi Matthias) (06/25/91)
wb1j+@andrew.cmu.edu (William M. Bumgarner) writes: I got sick of this silly handling, too. This is my opinion of how automount should handle opticals: every disk contains a label field where a host name is registered. setting this host name after initializing a new disk easely allows to detect if a disk is inserted into the drive it was formatted from! a) disk is inserted into the drive (mounted at the system) it was originally initialized from: - the disk will be mounted NO-SUID but with all ownerships correct set. - any new files will be created as usual - the ownerships of the creating user will be set. b) disk is inserted into a foreign drive (mounted at a foreign system) - the disk will be mounted NO-SUID an all ownership will be set to root, giving world rw-access. (maybe we could define something else here) - any new files will be created (physically written) as owned by root giving rw access to world. This procedure could even get refined by defining some additional flags in the disk label field: - allows to preserve ownerships - allows to modify existing files (no world r-flag is created) - etc. anyone feels like programming a new automounter ??? oh yeah! btw: we could also fake some directory entries which will request the appropriate optical disk. /MyArchive : if you type cd /MyArchive a fancy panel will show up: >>> Insert Optical Disk myArchive into drive 0 <<< just my opinion (probably not worth to be read.) matthias -- ----------------------------------------------------------------------- Matthias Heubi / NeXT / Atari ST / HP-48SX / mheubi@itr.ch -----------------------------------------------------------------------
windemut@lisboa.ks.uiuc.edu (Andreas Windemuth) (06/27/91)
In article <11043@idunno.Princeton.EDU> sksircar@shade.princeton.edu (Subrata Sircar) writes: > Wait. Are you people saying that if I log in to the Next, and insert a backup > optical disk (made by root) that all of the files on that disk are now owned > by me? Even if the mountable media has root-owned files? > > If so, that's not just stupid, that's criminal. What's to prevent anyone > from doing ANYTHING they want to a mountable medium, for example a source disk > mounted over a network? > Well, I think this is a grave misunderstanding of the issue. It has to be assumed, given the fact that you can carry the medium around, put it into a magnet or into a specially designed computer with an optical disk drive, the person in posession of the disk can do ANYTHING he or she likes to do to it anyway. The way to prevent that is to keep the disk out of unauthorized hands. That which has to be protected is not the disk (which can be easily protected by storing it in a safe), but the system that the disk is mounted on (assuming anyone can put his/her disk in, i.e. the system is not equipped with a padlock on the drive). If the ownerships were not correctly set to the user physically inserting the disk, anyone could fabricate data with arbitrary userid, including root. It has been correctly pointed out that this is a serious security problem in the case of suid programs, but it is in general a violation of the principle that it should not be possible to make one's own data appear to originate from somebody else (try chown on your files). Not to speak of the case where the users owning files on the disk don't even exist on the system the disk is inserted in. Thus, the way it is done now is neither stupid nor criminal, it is exactly how it should be. If you really want to mount a disk with other user's ownerships on it, you have to be superuser. You are then responsible for the integrity of the data on the medium. If I am not mistaken, this is indeed possible by mounting the optical drive like any other hard disk and inserting the disk itself on request. -- Andreas Windemuth +-------------------------------------------------------------------- |Theoretical Biophysics windemut@lisboa.ks.uiuc.edu |University of Illinois Tel: (217)-244-1612 |3121 Beckman Institute Fax: (217)-244-8371 |405 N Mathews, Urbana, IL61801 NeXTmail Ok +--------------------------------------------------------------------