From: rchandra@toz.buffalo.ny.us (Dr. R. Chandra)
Newsgroups: comp.unix.wizards
Subject: Re: correcton: restrictin
Date: 3 Sep 92 16:42:02 GMT
X-Maildoor: WaflineMail 1.00r

> In article <928@gofish.Stars.Reston.Unisys.COM> dymm@cards.com (David
> Dymm) writes:
> >I would like to set up a restricted directory tree
> >on my Sun 4 system.  That is, certain users, when logging on,
> >would be placed into accounts that would be located in a
> >directory tree that would not have access to the rest of
> >the system directory structure. ...
>
> The way my college did this was to create the restricted users
> in the 'peon' group-id.
> >All restricted directories were owned by group peon but with NO
> permissions.
> Correction: no GROUP permissions

I like this application.  On a UNIX system which I am writing software
for, I need root access on occasion, but it's a pain to inform me when
the password changes (for doing su(1) for instance), so I have a little
suid binary that does setuid(2) and setgid(2) to the proper values and
exec(2)s a shell.  Since it has to be owned by root, and for me to
execute it, it has to be "world" executable, and giving everyone on the
system a root shell would be a very Bad Thing, it is tucked away in a
subdirectory of my home directory where owner (me) has all permissions
and every other field has no permissions (the key one being search, or
"x").  Therefore, I am the only one besides root who has perms to do
anything to it.  The only difference then is the utmp entry.

> That way, owner and all other have access but NOT peon.
> Although this is contradictory to the intent of permission GRANTING
> vs. permission denial, it works.
>
> ex: /bin2 had commands that were not for peon use (moved over from
> /bin)
> dr-x---r-x   2 bin      peon         1664 Aug 26 16:14 /bin2
[...]
> As already mentioned an other postings, using the restricted shell
> also helps.
> I'm not sure if it was fixed, but there was a bug in how the shell
> determined if it was restricted or not.
> The old code checked for an 'r' in argv[0].  Anywhere in argv[0].
> This bit me when a login for 'smart' (a teaching program) used
> a C program that used 'system' to do something.
> The subshell inherited the argv[0] of 'smart' and since it contained
> an 'r', it went into restricted shell mode.
> The workaround was to alter argv[0] to something without any 'r'.

Ick!  I didn't know about that one.  Thanks!  I'll watch out for it now.

> Set root is tricky becuase you need hard links for all things in /dev,
> /tmp and other things that are below the new root.

Oh, really?  Granted, it is convenient from a system management
viewpoint (should anything in the true /dev/ change), but what's wrong
with mknod(1) in the "new root?"  All's the system needs is the major
and minor numbers from the inode, regardless of where in the directory
tree it gleans this info from.  And there's nothing inherently special
about /tmp either...just that most schemes mount a large disk or disk
partition on it.  That has definite advantages in a system failure (who
cares if fsck can't fix it?  Just mkfs with it and it'll be just fine).
So therefore, if the operative word is "need," I think not.  Desirable,
probably.

 * Q-Blue v0.7 [NR] *