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
jik@athena.mit.edu (Jonathan I. Kamens) (04/29/91)
(I've kept this in comp.unix.questions rather than following Eric's Followup-To, because what I'm posting has little to do with the NFS protocol directly.) In article <12681@uhccux.uhcc.Hawaii.Edu>, pilger@uhunix1.uhcc.Hawaii.Edu (Eric Pilger) writes: |> 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 |> |> SunOS does not let anyone but root issue the mount or umount command. Indeed. Blair apparently believes that general accessibility of mount() and umount() is the rule. In fact, it is the exception, and my impression is that only recently did *any* variant of Unix start allowing non-root users to do mounts. |> 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. Project Athena solved this problem several years ago by writing a program called "attach" (and a corresponding program called "detach") to do mounts and unmounts for users. It's more then just what Eric proposes. It supports several different filesystem types (UFS, NFS, RVD, AFS, and other special types); allows filesystems to be referred to by symbolic names (indeed, all user home directories are filesystems named after them, so the login program just runs "attach jik" to make my home directory accessible on a workstation); uses hesiod (another Project Athena thing) to look up filesystems or reads them from a configuration file (or both); allows the installer to configure whether or not users can do explicit attaches at all, and if so, what directories they can mount in and what directories they can't; and some other stuff. Unfortunately, we've never released attach for redistribution, because much of the NFS and UFS code was stolen from the BSD mount sources, which are not freely redistributable. We don't have any programmers working on it actively right now, so I don't know if/when the code is going to be freed of restrictions and distributed.n -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
pauld@stowe.cs.washington.edu (Paul Barton-Davis) (04/30/91)
Newsgroups: comp.unix.ultrix,comp.os.vms,comp.lang.postscript Subject: Re: Converting QMS to Postscript Summary: Expires: References: <13283.280dc44b@ecs.umass.edu> <45@ftms.UUCP> Sender: Reply-To: pauld@cs.washington.edu (Paul Barton-Davis) Followup-To: Distribution: Organization: Computer Science & Engineering, U. of Washington, Seattle Keywords: Newsgroups: talk.politics.theory Subject: Re: Can socialism and capitalism co-exist? Summary: Expires: References: <RJC.91Apr19185639@brodie.cstr.ed.ac.uk> <STEVEW.91Apr23104733@mushroom.cs.man.ac.uk> <1991Apr24.160222.3920@sdd.hp.com> Sender: Followup-To: Distribution: Organization: Computer Science & Engineering, U. of Washington, Seattle Keywords: months of research conclusively prove that no one reads this line Newsgroups: comp.unix.questions Subject: Re: Personal NFS? Summary: Expires: References: <4034@inews.intel.com> <12681@uhccux.uhcc.Hawaii.Edu> <1991Apr29.052922.4388@athena.mit.edu> Sender: Followup-To: Distribution: Organization: Computer Science & Engineering, U. of Washington, Seattle Keywords: Yes, for once SCO did something right. The system Jonathan describes from Athena shows up (presumably independtly) in SCO Unix/386, where the systerm administrator can set up "symbolic" names for filesystems, along with all their mount options, should they be fsck-ed, etc, etc. and a command pair (mnt and umnt, I recall) that lets any user (this is controllable too, I think) mount fsystems that are so defined. I actually like this a lot, and its the first thing about SCO's unix I've found that really should be emulated by one and all. -- Paul Barton-Davis <pauld@cs.washington.edu> UW Computer Science Lab "People cannot cooperate towards common goals if they are forced to compete with each other in order to guarantee their own survival."