grdetil@ccu.umanitoba.ca (Gilles R. Detillieux) (06/27/91)
Last week, I asked about preserving file ownerships on automounted optical disks. Now that the responses (posted and e-mailed) have ceased, I thought I should summarise. The definitive answer came from Joel McClung, at NeXT. (Thanks, Joel.) >The concept is that you could carry your entire world on an OD. >You'd just sit down at a machine and stick your OD in and everything >would just work. We couldn't guarantee that the UID would be the >same on two different machines so we just ignore the UID and GID if >someone other than root mounts the OD. The logic behind this is that >we wanted mere mortals to be able to use the disk w/o having to get >their local guru (sysadmin) person involved (which is what you >typically have to do to get work done on a [competitor's system]; >a model which we feel is broken). > >The statement you make about chown'ing an OD and it "sticking" in 1.0 >is incorrect. It would appear to stick, but if you ejected and >reinserted the disk, it would have the old ownerships. Or, if you >did a little work on other file systems and returned to the OD, it >would mysteriously start getting the old ownerships back because the >kernel buffer caches were gradually being flushed and re-read from >the disk. > >If root mounts the optical disk, then the ownership and group-ship >are maintained. Others suggested it is the automounter that does this, and if I use the /etc/mount command instead, it will do what I want. This is not right, as I discovered with some experimentation. If I log in as root at the NeXT console, then automount a disk, no UID or GID reassignment takes place. If I run /etc/mount as someone other than root, the reassignment does take place. The key is to mount as root. (I also discovered that although any user can run /etc/mount, only root can successfully run /etc/umount to unmount the disk, and /etc/disk -e /dev/rod0a to eject it.) It was also pointed out that this reassignment takes place on any media, not just the optical disk. Floppy disks, and even hard disks will be treated the same way. If you add a 2nd hard disk, you should add an entry to /etc/fstab so that the disk is automatically mounted as root when the system boots. Otherwise the system automounts the disk (when you log in?) as your personal disk and reassigns UIDs and GIDs. Someone also warned that without the UID reassignment, the system would be vulnerable to attack from set-uid programs on disks created on other machines. Of course, this can be controlled by giving the "-o nosuid" option to the /etc/mount command (see mount(8)). Note that if you mount disks as root that had been created while mounted by another user, you may have to change the ownerships of all the files (just the first time - the change will be permanent). When root mounts a disk that had been written earlier, while mounted by another user, all files belong to the user "root" and the group "wheel". (I assume that when a non-root user mounts a disk, the system not only ignores the UID and GID of files on the disk, but writes zeros for these in any files created while the disk is mounted by that user.) For those who don't know how to manually mount an optical disk (as opposed to letting the system automount it), here is the procedure: 1. Pop open a Terminal window, run "su" to become root, then type the mount command: /etc/mount /dev/od0a /mnt (or /etc/mount -o nosuid /dev...) You must enter this command before you insert the disk, otherwise it will be automounted. 2. Wait for the panel to pop up, asking you to insert the disk, then do so. 3. If the disk had previously be written while mounted by someone other than root, you may want to change the ownership (and groups) of files, eg: /etc/chown -R user.group /mnt/* 4. When done with the disk, you can't just eject it from the Workspace menu. (That works only with automounted disks.) To manually unmount and eject: /etc/umount /dev/od0a /etc/disk -e /dev/rod0a Note that if root automounts a disk whose root directory does not belong to "root", he will have to manually unmount and eject it. One respondant sent me two set-uid shell scripts to let users do all of the above. However, given the inherent security risks of setuid shell scripts, I don't recommend that approach. Hopefully NeXT will document this procedure better in the future. More hopefully, I'd like to see an option in the Workspace Manager to allow non-root users to automount disks without the UID and GID reassignment (and with set-uid programs on the disk disabled). Thanks to all who responded. -- 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