cwilson@NISC.SRI.COM (Chan Wilson [Animal]) (04/25/91)
Howdy all: I would have thought this would have been coved long since, but I haven`t been able to find any mention of any type of restricted shell for non-SYSV machines. Basically what i'm looking for is a shell that will only allow the user to access a specific subset of commands, and not progress upwards beyond a certain point in the directory tree. Now, I >can< go and hack my csh source, but i'd be more inclined to see if anyone else has come up with something already. It's amusing to note that while the ARCHIE server knows about resh, a restricted shell, there are no pointers to such a beastie, and searches for resh, restricted, and shell come up with little leads... Sigh. Help, please? --Chan Chan Wilson Chief Hard-Question Answer Person SRI Intl. Network Information Systems Center 333 Ravenswood Ave., EJ287 Internet: cwilson@nisc.sri.com Menlo Park, CA., 94025 Phone: (415)859-4492
jmason@gpu.utcs.utoronto.ca (Jamie Mason) (04/25/91)
In article <29183@fs1.NISC.SRI.COM> cwilson@NISC.SRI.COM (Chan Wilson [Animal]) writes: >I would have thought this would have been coved long since, but I >haven`t been able to find any mention of any type of restricted shell >for non-SYSV machines. Basically what i'm looking for is a shell that >will only allow the user to access a specific subset of commands, and >not progress upwards beyond a certain point in the directory tree. Flame: ON First of all, I have *used* one of those. They are real slimy and annoying for the users. Second, they are a pain for the administrators, since there are too many possible ways out via holes in programs which the user is permitted to run. Second, if you still want to run a facist shell, the facist shell which I was subjected to in first year was called 'lsh' and is a homebrew hack of the Bourne shell done at the U of T. I may be able to figure out who around here you should contact to ask about it. But I recomend against the idea... It is a pain for users and administrastors alike. On top of that, it is not that hard to get what you want, using a regular shell, via proper use of groups and modes. And last, keep in mind that restrictive policy tends to set the users and administators at each others throats, whereas open policy tends to foster a friendly atmosphere where the restrictions turn out not to be necessary since happy users just DO what you ASK without being forced to. Flame: OFF Sorry if there was a little too much flame in there. I was subjected to just such a restricted shell in the past, and it left a permanent scar. :-) Jamie ... Segmentation fault (core dumped) Written On Thursday, April 25, 1991 at 12:02:47am EDT
mills@ccu.umanitoba.ca (Gary Mills) (04/25/91)
In <29183@fs1.NISC.SRI.COM> cwilson@NISC.SRI.COM (Chan Wilson [Animal]) writes: >haven`t been able to find any mention of any type of restricted shell >for non-SYSV machines. Basically what i'm looking for is a shell that You may already have one. Try your Bourne shell with the ``-r'' flag. You might also try invoking it with the name ``rsh'' or ``resh''. I tried the ``-r'' flag under SunOS 4.1, and it worked, but only partially. If I remember correctly, it applied the restriction before /profile and .profile were interpreted, instead of afterwards. -- -Gary Mills- -Networking Group- -U of M Computer Services-
jc@raven.bu.edu (James Cameron) (04/26/91)
>>>>> On 25 Apr 91 04:03:44 GMT, jmason@gpu.utcs.utoronto.ca (Jamie Mason) said: JM> In article <29183@fs1.NISC.SRI.COM> cwilson@NISC.SRI.COM (Chan Wilson [Animal]) writes: >I would have thought this would have been coved long since, but I >haven`t been able to find any mention of any type of restricted shell >for non-SYSV machines. Basically what i'm looking for is a shell that >will only allow the user to access a specific subset of commands, and >not progress upwards beyond a certain point in the directory tree. JM> Flame: ON JM> First of all, I have *used* one of those. They are real slimy JM> and annoying for the users. Second, they are a pain for the JM> administrators, since there are too many possible ways out via holes in JM> programs which the user is permitted to run. [...deleted rest of message about the evils of a restricted shell...] JM> Flame: OFF JM> Sorry if there was a little too much flame in there. I was JM> subjected to just such a restricted shell in the past, and it left a JM> permanent scar. :-) JM> Jamie ... Segmentation fault (core dumped) JM> Written On Thursday, April 25, 1991 at 12:02:47am EDT Well, this is definately sometimes necessary. Take the following example: We have two full disks containing only data for our lab. We need to allow read access to this data, but nothing else. We don't have the disk space to simply copy the data over to the ftp files. So, basically, restricted shells *are* needed for special cases. Maybe I am forgetting something, but I don't think so. *8-) jc ps. Thanks again Jamie for the help!! -- -- James Cameron (jc@raven.bu.edu) Signal Processing and Interpretation Lab. Boston, Mass (617) 353-2879 ------------------------------------------------------------------------------ "But to risk we must, for the greatest hazard in life is to risk nothing. For the man or woman who risks nothing, has nothing, does nothing, is nothing." (Quote from the eulogy for the late Christa McAuliffe.)
bill@bilver.uucp (Bill Vermillion) (04/27/91)
In article <JC.91Apr25135941@raven.bu.edu- jc@raven.bu.edu (James Cameron) writes: ->>>>> On 25 Apr 91 04:03:44 GMT, jmason@gpu.utcs.utoronto.ca (Jamie Mason) said: - -JM> In article <29183@fs1.NISC.SRI.COM> cwilson@NISC.SRI.COM (Chan Wilson [Animal]) writes: -> Basically what i'm looking for is a shell that ->will only allow the user to access a specific subset of commands, and ->not progress upwards beyond a certain point in the directory tree. -JM> Sorry if there was a little too much flame in there. I was -JM> subjected to just such a restricted shell in the past, and it left a -JM> permanent scar. :-) -Well, this is definately sometimes necessary. Take the following example: -We have two full disks containing only data for our lab. We need -to allow read access to this data, but nothing else. We don't have ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -the disk space to simply copy the data over to the ftp files. So, -basically, restricted shells *are* needed for special cases. Maybe -I am forgetting something, but I don't think so. *8-) How about mounting the drives read only. /etc/mount /dev/whatever /wherever -r -- Bill Vermillion - UUCP: uunet!tarpit!bilver!bill : bill@bilver.UUCP
alan@ukpoit.co.uk (Alan Barclay) (05/03/91)
In article <JC.91Apr25135941@raven.bu.edu> jc@raven.bu.edu (James Cameron) writes: > >Well, this is definately sometimes necessary. Take the following example: > >We have two full disks containing only data for our lab. We need >to allow read access to this data, but nothing else. We don't have >the disk space to simply copy the data over to the ftp files. So, >basically, restricted shells *are* needed for special cases. Maybe >I am forgetting something, but I don't think so. *8-) > Why not mount the disks as read/only, this will give kernel level protection, must better than mucking around with restricted shells. -- Alan Barclay iT | E-mail : alan@ukpoit.uucp Barker Lane | BANG-STYLE : .....!ukc!ukpoit!alan CHESTERFIELD S40 1DY | VOICE : +44 246 214241