Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!oddjob!gargoyle!ihnp4!chinet!nucsrl!gore
From: gore@nucsrl.UUCP (Jacob Gore)
Newsgroups: comp.unix.wizards
Subject: Re: umask under 4.3
Message-ID: <3690004@nucsrl.UUCP>
Date: Sun, 31-May-87 13:54:05 EDT
Article-I.D.: nucsrl.3690004
Posted: Sun May 31 13:54:05 1987
Date-Received: Wed, 3-Jun-87 04:08:23 EDT
References: <7582@brl-adm.ARPA>
Organization: Northwestern U, Evanston IL, USA
Lines: 34

/ 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)