aru@mentor.cc.purdue.edu (Sri-Man) (06/18/91)
I was looking through the docs about formatting floppies and stuff, and right before it they were talking about mounting filesystems. On the Amiga, this means that we could mount a file system on the floppy, and this would definitely be a selling point for universities and educational facilities because you would be able to mount a filesystem for a user and that user can take his file system home with him. (hey, that would take care of quota problems!!) Solve a lot of problem in terms of disk usage on the system. This is most likely a very dense question, and I have not had a chance to take a look at other Release 4 systems. So here goes. Is there such a feature on the Unix boxes for the 486's?? I'm just looking for a selling point, so I can convince others at the CS department to buy it. Commodore guys: Hey, are 1.2meg floppy drives standard on the AmigaUX? For some reason I think I only got the regular 800K drive. On AmigaDOS I tried to format a floppy but it only gave me 875K rather than 1.2K. Just wondering.... Yours, Sri aru@mentor.cc.purdue.edu
avalon@coombs.anu.edu.au (Darren Reed) (06/18/91)
aru@mentor.cc.purdue.edu (Sri-Man) writes: >I was looking through the docs about formatting floppies and stuff, and right >before it they were talking about mounting filesystems. On the Amiga, this >means that we could mount a file system on the floppy, and this would definitely >be a selling point for universities and educational facilities because you would >be able to mount a filesystem for a user and that user can take his file system >home with him. (hey, that would take care of quota problems!!) Solve a lot of >problem in terms of disk usage on the system. But it means having the file syem write-able by the ordinary users. This opens up a nice can of worms with security, for more info see alt.security on info about this problem on Sun's. -avalon
cates504@pirates.armstrong.edu (06/19/91)
That is, indeed, the standard 720K floppy drive that comes std. on all Amigas. Under ADOS it will format to 837K, wait...no, no..it's 2.0 OS and hence a "FastFileSystem" device, yah, 875 is about right then. Applied Engineering makes a high density 3.5" drive for the Amiga, under ADOS it will format to about 1.5x megs, I believe. I doubt seriously that it's accessible from Amix yet it would be a natural for AE to write a driver for it. Jim
Mark.Stuart@actrix.gen.nz (Mark Stuart) (06/20/91)
In article <1991Jun18.225518.21818@pirates.armstrong.edu> cates504@pirates.armstrong.edu writes: > That is, indeed, the standard 720K floppy drive that comes std. on all > Amigas. Under ADOS it will format to 837K, wait...no, no..it's 2.0 OS > and hence a "FastFileSystem" device, yah, 875 is about right then. > > Applied Engineering makes a high density 3.5" drive for the Amiga, under > ADOS it will format to about 1.5x megs, I believe. I doubt seriously > that it's accessible from Amix yet it would be a natural for AE to > write a driver for it. > > Jim Commodore NZ are an interesting bunch, they have 2015 and 3015 1.44Mb 3.5" Disk Drives available for the Amiga (I presume that the 20/30 is for the 2000 series and 3000 series). I'm not sure if they actually have them yet, but they've got them yet. Their accounting system requires that if they order something, it must exist in the system first (which means when they export all their stuff to a dealer price list, interesting things creep in :-) ).
tim@proton.amd.com (Tim Olson) (06/20/91)
In article <13706@mentor.cc.purdue.edu> aru@mentor.cc.purdue.edu (Sri-Man) writes: | I was looking through the docs about formatting floppies and stuff, and right | before it they were talking about mounting filesystems. On the Amiga, this | means that we could mount a file system on the floppy, and this would definitely | be a selling point for universities and educational facilities because you would | be able to mount a filesystem for a user and that user can take his file system | home with him. (hey, that would take care of quota problems!!) Solve a lot of | problem in terms of disk usage on the system. File systems should only be mountable by root. Allowing a user to mount a floppy would be a big security hole. -- -- Tim Olson Advanced Micro Devices (tim@amd.com)
cates504@pirates.armstrong.edu (06/20/91)
Wha?! Kiwidrives? ;^) If those are real they should be released ASAP, I would wager they'd be "scarfed" up like hotcakes. Those AE drives are a bit, er...flaky? Jim
swarren@convex.com (Steve Warren) (06/20/91)
In article <1991Jun19.204906.19339@dvorak.amd.com> tim@amd.com (Tim Olson) writes: >File systems should only be mountable by root. Allowing a user to >mount a floppy would be a big security hole. It doesn't necessarilly have to be a security hole. There could be a standard partition at the / level reserved for the floppy filesystem. If a user wanted to mount his floppy-based filesystem, it would be treated in a secure way. Every inode would be scanned to make sure that nothing on the floppy violated the priviledges of the user. If anything bogus showed up then the system would refuse to mount it. We're only talking about 1.44 Meg, max. It shouldn't be that hard to do. How could any security violations get through if the system verified the security of the floppy? -- _. --Steve ._||__ Warren v\ *| V
frank@hfsi.UUCP (Frank McPherson Summer Intern) (06/21/91)
In article <1991Jun19.204906.19339@dvorak.amd.com> tim@amd.com (Tim Olson) writes: >| I was looking through the docs about formatting floppies and stuff, and right >| before it they were talking about mounting filesystems. On the Amiga, this >| means that we could mount a file system on the floppy, and this would definitely >| be a selling point for universities and educational facilities because you would >| be able to mount a filesystem for a user and that user can take his file system >| home with him. (hey, that would take care of quota problems!!) Solve a lot of >| problem in terms of disk usage on the system. > >File systems should only be mountable by root. Allowing a user to >mount a floppy would be a big security hole. > > -- Tim Olson If you restrict the mounting to floppies on a specific subtree, it's not that much of a security hole. For example, you could write a small program which would be called by a student which would mount a floppy disk residing in the internal disk drive to /sony, or something similar. That is, in fact, what is done at Virginia Tech. What we've got down there is a computer lab with four or five 3000UXD's which get used by many students. In order to avoid filling up the drives on the UXD's, we (the students) have to bring in a floppy which we use as our own personal travelling file system. It works out pretty well in the end. You could use cpio to save the stuff out and bring it back in every time you need to use it, but it seems simpler to just mount the floppy and use it as normal. Fewer extraneous details for the procrastinating student to worry about when they're trying to print out their code at the last minute. 8-) - Frank McPherson INTERNET: emcphers@manu.cs.vt.edu -
lance@mpd.tandem.com (Lance Hartmann) (06/21/91)
In article <1991Jun20.165331.4604@convex.com> swarren@convex.com (Steve Warren) writes: >In article <1991Jun19.204906.19339@dvorak.amd.com> tim@amd.com (Tim Olson) writes: >>File systems should only be mountable by root. Allowing a user to >>mount a floppy would be a big security hole. > >[STUFF DELETED] >Every inode would be scanned to make sure that nothing on the floppy violated >the priviledges of the user. If anything bogus showed up then the system >would refuse to mount it.... >[REMAINDER DELETED] Forgive my ignorance, but what do you mean by "scanning the inodes"? Yes, I know what an inode is, but I'm curious as to your procedure. I guess you could read the raw floppy device, check the super block, etc. before mounting, but is there a EASY, KNOWN way for checking the stat's of the raw contents? For example, you'd certainly want to make sure that there weren't ANY files with setuid/setgid bits set (particularly, root owned!). I know that all the info would be there, but am wondering how easy/difficult it would be to do this.... -- Lance G. Hartmann - cs.utexas.edu!devnull!lance (Internet) ------------------------------------------------------------------------------- DISCLAIMER: All opinions/actions expressed herein reflect those of my VERY OWN and shall NOT bear any reflection upon Tandem or anyone else for that matter.
swarren@convex.com (Steve Warren) (06/21/91)
In article <319@devnull.mpd.tandem.com> lance@mpd.tandem.com (Lance Hartmann) writes: >In article <1991Jun20.165331.4604@convex.com> swarren@convex.com (Steve Warren) writes: >>In article <1991Jun19.204906.19339@dvorak.amd.com> tim@amd.com (Tim Olson) writes: >>>File systems should only be mountable by root. Allowing a user to >>>mount a floppy would be a big security hole. >> >>[STUFF DELETED] >>Every inode would be scanned to make sure that nothing on the floppy violated >>the priviledges of the user. If anything bogus showed up then the system >>would refuse to mount it.... >>[REMAINDER DELETED] > >Forgive my ignorance, but what do you mean by "scanning the inodes"? Hey, I'm taking my first OS class right now! I can't tell you the nuts & bolts of how to do it, but I've never written a file system either! But what do you think fsck does? > ... I guess >you could read the raw floppy device, check the super block, etc. >before mounting, ... That is what I am talking about. > ... but is there a EASY, KNOWN way for checking the stat's of the >raw contents? For example, you'd certainly want to make sure that there >weren't ANY files with setuid/setgid bits set (particularly, root owned!). No root-owned files allowed. If the user does not have permission to write a file as root, then he can't mount a file-system containing root-owned files. >I know that all the info would be there, but am wondering how easy/difficult >it would be to do this.... It is simple. Just don't let the user do anything through a mount that he wouldn't otherwise be allowed to do through a direct creation of a directory or file. -- _. --Steve ._||__ Warren v\ *| V
malcolm@pandanus.ntu.edu.au (Malcolm Caldwell) (06/21/91)
I guess that it depends on what type of file system you mount. If the file system you mount has no facilities for setuid/setgid files then they can't be a problem. For example if an amiga dos filesystem was created for amiga unix, the mode bits could be set to some default, with the amiga bits being mapped to the 'other' mode bits. For more security the mode bits could be set so only the owner of the mount point can access the floppy, with the 'user' mode bits set from the amiga access bits. It is possible to mount a filesystem that has no way of being a security problem. -- Malcolm Caldwell malcolm@pandanus.ntu.edu.au Technical Officer Computer Science Northern Territory University, Darwin Australia
crash@ckctpa.UUCP (Frank J. Edwards) (06/22/91)
In article <426@hfsi.UUCP> emcphers@manu.cs.vt.edu (Frank McPherson) writes: > >If you restrict the mounting to floppies on a specific subtree, it's not >that much of a security hole. For example, you could write a small >program which would be called by a student which would mount a floppy >disk residing in the internal disk drive to /sony, or something similar. >That is, in fact, what is done at Virginia Tech. What we've got down >there is a computer lab with four or five 3000UXD's which get used by >many students. In order to avoid filling up the drives on the UXD's, >we (the students) have to bring in a floppy which we use as our own >personal travelling file system. It works out pretty well in the end. You could have other problems "in the end!" ;-) Suppose I make a floppy on my machine and put a copy of ksh on it. Then I make that ksh set-uid to root and mount it on your system. I execute that ksh and viola! I get the "#" prompt... >- Frank McPherson INTERNET: emcphers@manu.cs.vt.edu - Actually, the solution presented by Steve Warren is much sturdier: the same script would search the inodes looking for set-uid programs. If any were found, the disk would not be mounted. The "ncheck" command has an option, -s, which looks for set-uid files on the given media. It does not limit the output to any particular user ID, however. *** WARNING WILL ROBINSON *** NOTE: you can't mount the disk and run find!! Once you mount it, the user could access his set-uid program before the find command located the problem. Especially easy to do if you know that find looks through directory blocks sequentially... Anyway, maybe I'll write a script for this, but don't hold your breath ;-) Good luck. -- Frank J. Edwards | "I did make up my own mind -- there 2677 Arjay Court | simply WASN'T ANY OTHER choice!" Palm Harbor, FL 34684-4504 | -- Me Phone (813) 786-3675 (voice) | Only Amiga Makes It Possible...
bernie@metapro.DIALix.oz.au (Bernd Felsche) (06/22/91)
In <1991Jun21.110444.1049@darwin.ntu.edu.au> malcolm@pandanus.ntu.edu.au (Malcolm Caldwell) writes: >I guess that it depends on what type of file system you mount. If the file >system you mount has no facilities for setuid/setgid files then they can't >be a problem. Don't forget about device files. There's nothing quite like having your very own ./dev/dsk/* and other such lovely things to break into a system. -- Bernd Felsche, _--_|\ #include <std/disclaimer.h> Metapro Systems, / sold \ Fax: +61 9 472 3337 328 Albany Highway, \_.--._/ Phone: +61 9 362 9355 Victoria Park, Western Australia v Email: bernie@metapro.DIALix.oz.au
frank@hfsi.UUCP (Frank McPherson) (06/23/91)
In article <1991Jun21.201119.722@ckctpa.UUCP> crash@ckctpa.UUCP (Frank J. Edwards) writes: >Suppose I make a floppy on my machine and put a copy of ksh on it. Then >I make that ksh set-uid to root and mount it on your system. I execute >that ksh and viola! I get the "#" prompt... > Would you have to meddle around with the KSH to make it set-uid to root? My point here is, if you started up a ksh, even if from your own file system, shoudn't it disallow you to setuid to root? If not, that is a pretty serious security hole in the way we're doing things. I'm not sure that it really MATTERS, because the machines aren't incredibly important anyway, and there aren't any overwhelming reasons for someone to want root access on one of them, other than just saying they did it. >Actually, the solution presented by Steve Warren is much sturdier: the >same script would search the inodes looking for set-uid programs. If >any were found, the disk would not be mounted. > That makes good sense. -- Frank McPherson INTERNET: emcphers@manu.cs.vt.edu --
sysop@insider.zer.sub.org (06/23/91)
> File systems should only be mountable by root. Allowing a user to > mount a floppy would be a big security hole. So ? Where's the difference if one get's the data via TAR or direct by mounting ? Amiga - What else ? | Garry Glendown The Insider HST/V32b +49 (0)6621-77923 // | UUCP: cbmvax!cbmger!insider!garry Fido: 2:243/43.999 // | garry@fulmin.rhoen.sub.org Garry@DGIHRZ01.BITNET \X/ | Zerberus: SYSOP@INSIDER.ZER **>>> MPoint v1.6 <<<** (C)1991 M.Aberle
swarren@convex.com (Steve Warren) (06/24/91)
In article <431@hfsi.UUCP> frank@hfsi.UUCP (Frank McPherson) writes: >Would you have to meddle around with the KSH to make it set-uid to root? >My point here is, if you started up a ksh, even if from your own file >system, shoudn't it disallow you to setuid to root? If not, that is a >pretty serious security hole in the way we're doing things. You don't need to execute ksh to make it into a setuid executable. That is a quality of the file, like the protection bits. You change this using the chmod command. Once the file that is the ksh executable is chmod'd to setuid to root, it of course will do this every time this file is executed. That is why such files are jealously guarded by good sys-admins. On a machine in which you do not have super-user permission you would not be able to chmod any files to setuid-root. However, on your own personal property machine you would of course be the super-user. You could create setuid-root files to your heart's content. What is at issue here is the concern that you could transfer this file to another system without your permission to do so being questioned. The new system, believing that only the super-user has permission to *create* such files, would not hesitate to perform the setuid-root operation when any file with the setuid-root mode was executed. The idea of security is that the OS must be able to supervise the permissions of all files introduced by non-root users. This means that any scheme allowing non-root users to mount filesystems must include a bullet-proof way of verifying the permissions of all files on the new filesystem. Once they are verified there must also be a check to make certain that the user does not mount a filesystem and then swap disks with an identical filesystem, but different permissions on the identical files. The Amiga should permit this extra check, because it monitors the floppy drive, and it is possible to note each time a floppy is removed from the system. At that point the user-mounted filesystem should be unmounted, because once the floppy is removed from the system there is no guarantee that the disk will be returned unmodified. > ... I'm not >sure that it really MATTERS, because the machines aren't incredibly >important anyway, and there aren't any overwhelming reasons for someone >to want root access on one of them, other than just saying they did it. Well, if these machines are being used for classwork then what this security hole means is that any student who is sufficiently motivated may gain access to the programs of every other student who has an account on the same machine. A dedicated hacker could wreak all kinds of havoc after finding this hole. How about writing a daemon that runs quietly and secretly copies every floppy that students mount, to the harddrive? I think that this represents an overwhelming reason to want root access to a small portion of students at any university. That is one reason why those protections are there. -- _. --Steve ._||__ Warren v\ *| V
avalon@coombs.anu.edu.au (Darren Reed) (06/24/91)
frank@hfsi.UUCP (Frank McPherson) writes: >In article <1991Jun21.201119.722@ckctpa.UUCP> crash@ckctpa.UUCP (Frank J. Edwards) writes: >>Suppose I make a floppy on my machine and put a copy of ksh on it. Then >>I make that ksh set-uid to root and mount it on your system. I execute >>that ksh and viola! I get the "#" prompt... >> >Would you have to meddle around with the KSH to make it set-uid to root? >My point here is, if you started up a ksh, even if from your own file >system, shoudn't it disallow you to setuid to root? If not, that is a [...] it is a bit of security problem, the Amiga3000UX should come with an entry for /dev/dsk/fd0 in one of the files in /etc (maybe fstab but commented out) to make it easier for novices to mount the floppy drive (not as easy as if sounds for a novice!) and to have it mount with the correct options - it is possible to mount a device under unix and have it IGNORE setuid bits - its just that most devices are mounted "setall". The default is "setall" i believe, so that if you mount a floopy without disabling setuid programs people can quite easily create setuid programs on floppy disks and execute them on your 3000. Under AMIX both sh/csh disallow you to run suid shell scripts - you need at least *one* shell which will let you create/run setuid shell scipts. darren
frank@hfsi.UUCP (Frank McPherson) (06/24/91)
In article <1991Jun24.005213.944@convex.com> swarren@convex.com (Steve Warren) writes: >On a machine in which you do not have super-user permission you would not be >able to chmod any files to setuid-root. However, on your own personal >property machine you would of course be the super-user. You could create >setuid-root files to your heart's content. What is at issue here is the >concern that you could transfer this file to another system without your >permission to do so being questioned. The new system, believing that only the >super-user has permission to *create* such files, would not hesitate to >perform the setuid-root operation when any file with the setuid-root mode was >executed. Good point. I hadn't completely considered the issue, and didn't completely understand the implications. Thanks for pointing them out and taking the time to explain them. >The idea of security is that the OS must be able to supervise the permissions >of all files introduced by non-root users. This means that any scheme >allowing non-root users to mount filesystems must include a bullet-proof way >of verifying the permissions of all files on the new filesystem. That's something I don't believe the current system does. I can't check right at the moment, because I'm at work, but I certainly will when I get home. Fsck is automatically performed on each floppy file system before it is mounted, but I don't think any checking of the permissions is done. >Once they are verified there must also be a check to make certain that the >user does not mount a filesystem and then swap disks with an identical >filesystem, but different permissions on the identical files. >At that >point the user-mounted filesystem should be unmounted, because once the floppy >is removed from the system there is no guarantee that the disk will be >returned unmodified. Another good point. I know AmigaDOS checks for diskchange, but does Amiga Unix? Is recognizing diskchange part of the hardware of the Amiga, or is it the software? I'm kind of confused about that, since under AmigaDOS the drives click, but the clicking may be turned off with several of public domain programs. AmigaUNIX doesn't seem to notice if I take a disk out of the drive, except perhaps when it tries to synch it. People often will forget to unmount floppies before they leave, which is an ugly problem. > >How about writing a daemon that runs quietly and secretly copies every floppy >that students mount, to the harddrive? I think that this represents an >overwhelming reason to want root access to a small portion of students at any >university. That is one reason why those protections are there. Normally, it isn't possible for the student to store things on the hard drives of the machines in question. The home directory of the guest account is cleared out by the default system login. However, it is easily possible to save files elsewhere on the file system so that they don't get deleted when someone else logs in. The only reason someone would have to make copies of files would be to copy their work; this is indeed a problem. It would be nice if people didn't do things like that, but sometimes they do. -- Frank McPherson INTERNET: emcphers@manu.cs.vt.edu --
frank@hfsi.UUCP (Frank McPherson) (06/24/91)
In article <avalon.677734203@coombs> avalon@coombs.anu.edu.au (Darren Reed) writes: >it is a bit of security problem, the Amiga3000UX should come with an >entry for /dev/dsk/fd0 in one of the files in /etc (maybe fstab but >commented out) to make it easier for novices to mount the floppy >drive (not as easy as if sounds for a novice!) and to have it mount >with the correct options - it is possible to mount a device under unix >and have it IGNORE setuid bits - its just that most devices are mounted >"setall". The default is "setall" i believe, so that if you mount a >floopy without disabling setuid programs people can quite easily create >setuid programs on floppy disks and execute them on your 3000. It's currently easy for novices to mount the floppy drives; what I'm unsure about now is the setuid thing. It's news to me that you can mount it to ignore the file mode bits; maybe I need to get friendly with the manuals for an evening to try to figure this one out. It's currently getting looked at much more closely than I ever have, so things keep popping up which I hadn't really considered. I wonder if the people who set up the lab systems for my school considered them? At any rate, I'll go home and try to check the options used with the mount command currently in place. -- Frank McPherson INTERNET: emcphers@manu.cs.vt.edu --
swarren@convex.com (Steve Warren) (06/25/91)
In article <432@hfsi.UUCP> emcphers@manu.cs.vt.edu (Frank McPherson) writes: >In article <1991Jun24.005213.944@convex.com> swarren@convex.com (Steve Warren) writes: [...] >>How about writing a daemon that runs quietly and secretly copies every floppy >>that students mount, to the harddrive? I think that this represents an >>overwhelming reason to want root access to a small portion of students at any >>university. That is one reason why those protections are there. > >Normally, it isn't possible for the student to store things on the hard >drives of the machines in question. [...] But then we're not talking about "normally," are we? We are discussing a security hole that allows anyone with one semester of OS knowledge to become root on all of these machines (the ones with your custom floppy filesystem hack on them). Once you become root, forget about restrictions of where you can store files. There are none. Root is the boss. -- _. --Steve ._||__ Warren v\ *| V
frank@hfsi.UUCP (Frank McPherson) (06/25/91)
In article <1991Jun24.173951.17552@convex.com> swarren@convex.com (Steve Warren) writes: > [...] >But then we're not talking about "normally," are we? We are discussing >a security hole that allows anyone with one semester of OS knowledge to >become root on all of these machines (the ones with your custom floppy >filesystem hack on them). Once you become root, forget about restrictions >of where you can store files. There are none. Root is the boss. I'm curious: how do you propose to fix this? Is it an operating system problem? Is it possible to securly allow anyone to mount a floppy? From what you've already said, I guess that requires asking if it's possible to make sure that there are no setuid'd files on the disk, or it means ignoring the setuid bit. Which would be better? Why would it be better? - Frank McPherson INTERNET: emcphers@manu.cs.vt.edu --
swarren@convex.com (Steve Warren) (06/25/91)
In article <436@hfsi.UUCP> emcphers@manu.cs.vt.edu (Frank McPherson) writes: [...] >From what you've already said, I guess that requires asking if it's >possible to make sure that there are no setuid'd files on the disk, or >it means ignoring the setuid bit. Which would be better? Why would it >be better? Ignoring the setuid would certainly be orders of magnitude simpler to implement. Off hand I can't think of any reason a user would need files that were setuid to himself, since he is already himself. ;^) He can't create files that are setuid to anyone else unless he is root, and no one else is depending on files that are setuid to himself, because his filesystem is temporary. Can anyone think of a reason why setuid bits need to be securely enabled (as opposed to being ignored) on a temporary filesystem like a floppy disk? -- _. --Steve ._||__ Warren v\ *| V
karl@prophet.UUCP (Karl-Gunnar Hultland) (06/27/91)
>In article <431@hfsi.UUCP> frank@hfsi.UUCP (Frank McPherson) writes: >In article <1991Jun21.201119.722@ckctpa.UUCP> crash@ckctpa.UUCP (Frank J. Edwards) writes: >>Suppose I make a floppy on my machine and put a copy of ksh on it. Then >>I make that ksh set-uid to root and mount it on your system. I execute >>that ksh and viola! I get the "#" prompt... >> >Would you have to meddle around with the KSH to make it set-uid to root? >My point here is, if you started up a ksh, even if from your own file >system, shoudn't it disallow you to setuid to root? If not, that is a >pretty serious security hole in the way we're doing things. I'm not >sure that it really MATTERS, because the machines aren't incredibly >important anyway, and there aren't any overwhelming reasons for someone >to want root access on one of them, other than just saying they did it. > If I OWN an own A3000 running UNIX the I could easy make a set-uid root ksh on a floppy. That's not REALLY a security hole. Karl --- Karl Hultland, {rutgers | pyramid | uunet}!cmbvax!cbmehq!cbmswe!prophet!karl Organization: Mine all mine. Egoist: a person of low taste, more interested in himself than in me. - A. Bierce
ag@amix.commodore.com (Keith Gabryelski) (06/27/91)
sysop@insider.zer.sub.org writes: > > File systems should only be mountable by root. Allowing a user to > > mount a floppy would be a big security hole. > > So ? Where's the difference if one get's the data via TAR or direct by > mounting ? The data is not the problem. The setuidness off the file is. tar creates a file by taking the data from the specified archive and placing it in a file using standard unix system calles (open, write, close). The archive happens to have permissions which include setuidness which are given to the create file if the user that is extracting the file has permission. mount places a filesystem (a set of files in a kernel known format) in the unix hierarchy by an entirely different unix mechanism which does not require interpretting the permission bits of individual files until said file is accessed. Pax, Keith -- Keith Gabryelski Advanced Products Group ag@amix.commodore.com ...!cbmvax!amix!ag
swarren@convex.com (Steve Warren) (06/27/91)
In article <2762@amix.commodore.com> ag@amix.commodore.com (Keith Gabryelski) writes: [...] >mount places a filesystem (a set of files in a kernel known format) in >the unix hierarchy by an entirely different unix mechanism which does >not require interpretting the permission bits of individual files until >said file is accessed. Yes, in order to do this securely something besides mount would have to do verification and then call mount (you would not allow the user to call mount directly). --