guru@buhub.bradley.edu (Jerry Whelan) (04/24/91)
Once upon a time, a friend of mine mentioned in passing a package that would allow a normal user to mount remote filesystems in said user's home directory. The friend is now gone, but I'd really like to exactly this. I don't care if all setuid bits are masked off on the mounted filesystem, I just need to access data files that are sitting on it. I believe that my friend said the thing worked through nfs. A search on archie at McGill turned up a lot of 'nfs's but nothing that sounded like what I'm looking for. So, can anyone give me any leads? -- "I'm not sure what I mean, so I'm going to listen to what I say." guru@ (buhub.bradley.edu || bucc1.bradley.edu) || whelan@wiliki.eng.hawaii.edu
bhoughto@pima.intel.com (Blair P. Houghton) (04/26/91)
In article <1991Apr24.000005.7810@bradley.bradley.edu> guru@buhub.bradley.edu (Jerry Whelan) writes: > Once upon a time, a friend of mine mentioned in passing a package >that would allow a normal user to mount remote filesystems in said user's >home directory. This sounds oddly undescriptive, but the obvious answer is to cd $HOME mkdir foo mount -t nfs /bar/bletch@uunet foo and wait (usually milliseconds) for nfs to find and mount the fs. To get to the file /bar/bletch/bazz on uunet, the path is $HOME/foo/bazz, or ~/foo/bazz, or /usr/noodles/nudelman/bazz, if you're Nudelman. When you're done, do cd $HOME umount -f foo rmdir foo Basically, RTFM mount(8) and umount(8). If your sysadmin has turned off your permission to invoke mount or umount, scream loudly. The only thing you need to do either is write permission in the directory, and the right sort of connectivity to the remote system (most routers and gateways prevent nfs activity through them, but the workstation in the next cubicle is a short hop). --Blair "I scratch my head."
jeffe@eniac.seas.upenn.edu (george) (04/26/91)
: :Basically, RTFM mount(8) and umount(8). If your sysadmin has :turned off your permission to invoke mount or umount, scream :loudly. The only thing you need to do either is write permission With my SunOs it came "turned off" out of the box. The manual doesn't give any indication of how to turn it on. Any Ideas? -- -george george@mech.seas.upenn.edu
barmar@think.com (Barry Margolin) (04/26/91)
In article <4034@inews.intel.com> bhoughto@pima.intel.com (Blair P. Houghton) writes: >Basically, RTFM mount(8) and umount(8). If your sysadmin has >turned off your permission to invoke mount or umount, scream >loudly. The only thing you need to do either is write permission >in the directory, and the right sort of connectivity to the >remote system (most routers and gateways prevent nfs activity >through them, but the workstation in the next cubicle is a >short hop). According to the SunOS 4.1.1 man page, "mount(2) may be invoked only be the super-user." Mount(8) generally isn't setuid, so it inherits this restriction. There are good reasons for this. A mount command that can be used by ordinary users would have to be very careful. It would have to turn on the "nosuid" option so that the user couldn't create security holes by mounting a remote file system that has unwanted setuid-root programs. Another problem is if the remote file system contains device special files. I've always believed that the nosuid option should also disable recognition of device files, but most implementations don't do this. So, the remote file system could contain a device file with the same major and minor device numbers as /dev/kmem, but owned by the user doing the mount. This is a big security hole. It's not true that "most routers and gateways prevent nfs activity through them". Most routers and gateways just pass everything through. Some routers can be configured to censor what they pass (we use such a router for our connection to the Internet), but it's probably not the case that most sites use this feature. However, most NFS servers have a configuration file that lists who they will allow to mount their file systems. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
pilger@uhunix1.uhcc.Hawaii.Edu (Eric Pilger) (04/27/91)
In article <4034@inews.intel.com> bhoughto@pima.intel.com (Blair P. Houghton) writes: > > cd $HOME > mkdir foo > mount -t nfs /bar/bletch@uunet foo Actually, SunOS insists on: mount -t nfs uunet:/bar/bletch $HOME/foo > cd $HOME > umount -f foo Once again, SunOS insists on: umount $HOME/foo > rmdir foo > >Basically, RTFM mount(8) and umount(8). If your sysadmin has >turned off your permission to invoke mount or umount, scream SunOS does not let anyone but root issue the mount or umount command. I suppose you could change these commands to be SUID, but I would only want to do this on my own personal machine. IT WOULD NOT be a wise thing to do generally. The safest path is to create a small program that is hardwired to do specific mounts, and make it SUID. This provides a little more control. >loudly. The only thing you need to do either is write permission >in the directory, and the right sort of connectivity to the AND make sure the file system you're trying to mount from the remote machine is exported to you. Check the /etc/exports file. >remote system (most routers and gateways prevent nfs activity Eric Pilger Systems Programmer NASA Infrared Telescope Facility 2680 Woodlawn Drive Honolulu, HI 96822
adrianho@barkley.berkeley.edu (Adrian J Ho) (04/27/91)
In article <12681@uhccux.uhcc.Hawaii.Edu> pilger@uhunix1.uhcc.Hawaii.Edu (Eric Pilger) writes: >>loudly. The only thing you need to do either is write permission >>in the directory, and the right sort of connectivity to the >AND make sure the file system you're trying to mount from the remote machine >is exported to you. Check the /etc/exports file. Or, if you don't have access to the remote machine: showmount -e <remote_host_name> Personally, I'd trust showmount more than /etc/exports. Some systems (eg. SunOS) require you to run exportfs(8) after you update /etc/exports to get the desired effect, while others (eg. Ultrix) don't. If (like me) you have to deal with a mix of the two, it's all too easy to forget that second step. -- ----------------------------------------------------------------------------- Adrian Ho, EECS (pronounced "eeks!") Dept. Phone: (415) 642-5563 UC Berkeley adrianho@barkley.berkeley.edu