jfh@rpp386.cactus.org (John F Haugh II) (03/25/91)
In article <1991Mar21.175748.27202@NCoast.ORG> jeffl@NCoast.ORG (Jeff Leyser) writes: >In post <1991Mar18.045734.5114@brolga.cc.uq.oz.au>, ggm@brolga.cc.uq.oz.au (George Michaelson) says: >!How "invisible" are they? Can this be exploited meaningfully by sysops >!or others to provide secure online storage of files you don't want >!mortals to know about? (/usr is a bad example. unmounting makes the >!system pretty useless. some other places might be more bearable.) > >They're completely invisible, at lease to all "useful" utilities. The >only way to manipulate the "hidden" would be by i-node numbers, and I >don't think anything other than fsdb will be able to do that for you. >Of course, unmounting the "overlay" will allow you to manipulate the (no >longer) hidden files in the usual manner. No, they are quite visible to the "dump" utility, and you can infact recover the files by dumping the partition and then extracting the files from the dump tape. Of course this is cheating since "dump" reads the raw partition, but I didn't want people to go away with the impression that you can't get to files under a mount point. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.
mitch@hq.af.mil (Mitch Wright) (03/27/91)
/* * On 21 Mar 91 17:57:48 GMT, * In article <1991Mar21.175748.27202@NCoast.ORG>, * jeffl@NCoast.ORG (Jeff Leyser) said: * */ George> If you have some files in a directory eg /usr (on the root partition) George> and you mount the filesystem /usr over them, they become "invisible". Jeff> Of course, unmounting the "overlay" will allow you to manipulate the (no Jeff> longer) hidden files in the usual manner. Jeff> But there several better ways to do what (I think) you want. Place the Jeff> files in a directory owned by root, with permission of 700. Users will Jeff> [...] Just write your own library routines that quickly unmount the fs, open the file, and then remount. ~mitch mitch@hq.af.mil (Mitch Wright) | The Pentagon, 1B1046 | (703) 695-0262
jik@athena.mit.edu (Jonathan I. Kamens) (04/03/91)
In article <MITCH.91Mar26123609@hq.af.mil>, mitch@hq.af.mil (Mitch Wright) writes: |> Just write your own library routines that quickly unmount the fs, open the |> file, and then remount. This will only work if no process has any files open on the filesystem you're trying to unmount. In the case of a filesystem like /usr, it is very unlikely that no one will have any open files on it when you go to unmount it. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
rden@rden.gen.nz (Robert den Hartog) (04/07/91)
In article <1991Apr3.140229.3474@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >In article <MITCH.91Mar26123609@hq.af.mil>, mitch@hq.af.mil (Mitch Wright) writes: >|> Just write your own library routines that quickly unmount the fs, open the >|> file, and then remount. > > This will only work if no process has any files open on the filesystem >you're trying to unmount. In the case of a filesystem like /usr, it is very >unlikely that no one will have any open files on it when you go to unmount it. > While at university we had a little project to read files in a directory with no read/scan permission, but with read access to the device. It was just a matter of getting the inode number for the dir, read the blocks and get the inode number for the file, then read the file. By adding this together with the source for ls, I had quite a sofisticated read anything combined ls/cat program. (this was v6, and we didn't have access to fsdb, anyway my little program was more useful for my purposes.) Why could the same thing not be used here, all one needs is to get the inode number of the dir the file system is mounted on, and setuid or similar to the owner of the device it is on. Hence also lib routines could likewise be written. -- The possums are destroying our forests, the rabbits are destroying our farms, the wasps are destroying our parks, human extravegance our environment, but what's worse, the government is destroying us. Hey, have a nice one. Robert den Hartog. {rden|robert}@{rden|mercury}.gen.nz ...If it don't work, yell it, I like bang paths, they work.
greywolf@unisoft.UUCP (The Grey Wolf) (04/11/91)
/* <1991Apr3.140229.3474@athena.mit.edu> by jik@athena.mit.edu (Jonathan I. Kamens)
* In article <MITCH.91Mar26123609@hq.af.mil>, mitch@hq.af.mil (Mitch Wright) writes:
* |> Just write your own library routines that quickly unmount the fs, open the
* |> file, and then remount.
*
* This will only work if no process has any files open on the filesystem
* you're trying to unmount. In the case of a filesystem like /usr, it is very
* unlikely that no one will have any open files on it when you go to unmount it.
Not to mention that if you manage to nfs-mount the parent fs of the fs in
question, you can get to the file anyway (though permissions can take care
of that if you use the extreme fascistic permission scheme for your precious
files...). It's kind of like sweeping things under the rug on the main
system and then using some other system to turn 2-dimensional and make your
way under the rug...
It's a side effect which is better avoided.
*
* --
* Jonathan Kamens USnail:
* MIT Project Athena 11 Ashford Terrace
* jik@Athena.MIT.EDU Allston, MA 02134
* Office: 617-253-8085 Home: 617-782-0710