Hampton@DOCKMASTER.arpa (05/29/87)
Jon,
I did a similar thing on 4.2 BSD. I made three changes. The first
two changes were to the default umask values in 'sh' and 'csh'. The
third change was to the kernel, affecting all files created by creat()
where the protection was not specified. This value is somewhere in
/sys/sys, I believe. Look for a definie for UMASK. (I made this change
some five months ago, so the details are fuzzy. I can check at work
tomorrow.)
David R. Hamptongwyn@brl-smoke.ARPA (Doug Gwyn ) (05/29/87)
In article <7578@brl-adm.ARPA> Hampton@DOCKMASTER.arpa (David R. Hampton) writes: >/sys/sys, I believe. Look for a definie for UMASK. (I made this change Do you guys seriously believe that you're improving security by this? Or do you just like to prevent people from sharing and cooperating?
bzs@bu-cs.bu.EDU (Barry Shein) (05/29/87)
I always figured a good way to do these kinds of things (set the umask etc) would be to use a program other than the shell in a user's login entry and then use that to exec or fork (if there's post-processing desired, I used that once to produce summary session accounting records so I could shut off per-process accounting but still produce short summaries with minimal disk space, just write out the user's getrusage() structure when the shell fork returns) the user's shell. It's probably a tiny process that gets swapped right out if need be as it just sits in a wait() (if forked, if the shell is exec'd it's gone.) This doesn't require sources and seems much more flexible, just change a user's passwd entry to something like: johndoe::uid:gid:gecos:homedir:/bin/shell It could be setuid if need be and it would be easy to check argv[0] as a hook for which shell to start, /bin/cshell etc. You could re-work environment variables before starting the user's shell, limits, whatever, even install things like permissible login time windows or other security hooks (secondary password, secure ttys etc.) Might have to play with chsh but other than that I don't think there would be much problem. There are a number of details, some poorly documented (eg. args that need to be passed) but fairly easily determined heuristically (the first cut could dump argv and envp.) I dunno, seems like a nice and general hook. Could be a good net.sources contribution by someone all full of hooks for typical needs. -Barry Shein, Boston University
gore@nucsrl.UUCP (Jacob Gore) (05/31/87)
/ nucsrl:comp.unix.wizards / bzs@bu-cs.bu.EDU (Barry Shein) / > >I always figured a good way to do these kinds of things (set the umask >etc) would be to use a program other than the shell in a user's login >entry and then use that to exec or fork [...] the user's shell. > > [...] just change a user's passwd entry to something like: > >johndoe::uid:gid:gecos:homedir:/bin/shell > >It could be setuid if need be and it would be easy to check argv[0] as >a hook for which shell to start, /bin/cshell etc. This is what we do on our 4.3bsd VAXes (for some reason, it doesn't work on Sun OS 3.2), except we just use a shell script, known by the names /etc/sh.start, /etc/csh.start and no on. This way, `basename $0 .start` gives you the shell to use. >There are a number of details, some poorly documented (eg. args that >need to be passed) but fairly easily determined heuristically [...] In our case, the actual shell is exec'ed from a short program whose sole purpose is to stick a '-' in front of the shell's name, so that it's known to be a login shell. HOWEVER, that exec fails on a Sun (OS 3.2)! It works fine if you are already logged in and just envoke /etc/csh.start (it creates a subshell that behaves like a login process), but not if it's the login shell in your /etc/passwd entry. Is this some security check that Sun put in? Jacob Gore Northwestern University, Computer Science Research Lab {gargoyle,ihnp4,chinet}!nucsrl!gore gore@EECS.NWU.Edu (for now, only from ARPA)
toby@gargoyle.UChicago.EDU (Toby Harness) (06/01/87)
In article <7582@brl-adm.ARPA> bzs@bu-cs.bu.EDU (Barry Shein) suggests: .... >johndoe::uid:gid:gecos:homedir:/bin/shell > >It could be setuid if need be and it would be easy to check argv[0] as >a hook for which shell to start, /bin/cshell etc. You could re-work >environment variables before starting the user's shell, limits, >whatever, even install things like permissible login time windows or >other security hooks (secondary password, secure ttys etc.) Might have >to play with chsh but other than that I don't think there would be >much problem. > >There are a number of details, some poorly documented... Two things to look out for, both involving other programs cranking-up a sub-shell: most look at $SHELL, so be sure to reset it to the shell you are exec'ing; some use the entry in /etc/passwd -- one way around this would be to check if (ppid() != 1) and skip everything you want done only at login. Toby Harness Ogburn/Stouffer Center, University of Chicago ...ihnp4!gargoyle!toby
escott%deis.UCI.EDU@ROME.UCI.EDU (06/02/87)
While you're at it, don't forget to add a call to umask() in the rshd in 4.2BSD. Missing this can be a true bummer if you generally log into only one system and then get to other systems using X... Scott escott@ics.uci.edu ...!ucbvax!ucivax!escott
rob@philabs.UUCP (06/04/87)
In article <5905@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >> ......how to change the default umask ..... >Do you guys seriously believe that you're improving security by this? >Or do you just like to prevent people from sharing and cooperating? Sometimes it's nice to keep a not so knowledgeable user's files protected. Such as a student who just completed an assignment... Sometimes you want sharing and cooperation as the default, some times you don't. If nothing else more intellegent users can reset their umasks in their .login/.profile. rob -- william robertson rob@philabs.philips.com