> > % The shell_command field would be run as 'sh -c "shell_command"'
> > % with the following environment variable guaranteed to be set:
> > % 
> > % 	USER=user_name
> > 
> > Also need GROUP for the user's group name.
> > Might be nice to have TTY as the login tty's name.
> 
> Agreed on TTY="tty_name" but why does anyone need GROUP in
> the environment?  After a new login, the tty and all related
> devices should be owned by the user, group=tty, and mode=0600.
> They own all the devices at that point, so they can change the
> group and modes however they please.  I say let the user do it.

Why would you _ever_ want to have, say, a disk device owned by the
'tty' group?

In the 'small' environments that I set up, typically users have GID ==
UID == some unique value, i.e. each is in their own group, and any
additional groups, so they can use 002 umasks and not worry about
keeping files private.  What _i'd_ typically want to do is chgrp
random devices to their GID, so they had exclusive access, if that
made sense for the device (e.g. for 'console' disk devices).


How much work is it to supply 'group'?  it's already in the 'struct
pwent' for the user, and you can translate it into a name with
getgrgid()...

On the other hand, as i pointed out previously, users _can_ get
'${GROUP}' functionality without ${GROUP}.


> > The advantages that are important is a way easily to do things
> > with the user's group, and the ability to specify login and logout
> > actions together for maintainability.  OTOH, this proposal is simpler
> > and cleaner.  So, I propose the above changes to Gordon's proposal as a
> > compromise (actually, I think I like it better). Is this agreeable?
> 
> How is it useful to "do things with the user's group"?
> What would you do that the usr could not do just as well?

The user can do many things.  However, that doesn't mean that the user
should have to.


> How do you justify the additional complexity of the "action" field?
> (You might avoid forking a shell, but is that a big deal?)

I would argue that there is very little additional complexity.  Show
me the code that you'd implement the file parsing with, and i'll bet
that adding 'action' support would be very simple (one more strtok(),
one more search for whitespace, etc.).  The same mechansim that you
use to get the TTY name could be used to get the action name, and
that's not going to be very tough in either case.


I also must admit that, for the class of uses that I think we're going
to see this used for, it's much more sane to administer multiple
actions with one file.

For instance, right now we have "login" and "logout."  Say somebody
wants to add "logincheck" to do what I suggested in a previous mail
message.  With a multiple-file scheme, they now have to manage three
files which talk about actions that happen at login and login out a
given tty (not including /etc/ttys).  I'd much rather have one file
eith entries like:

tty0	logincheck	/somewhere/check_frob ${TTY}
tty0	login		/somewhere/login_frob ${TTY}
tty0	logout		/somewhere/logout_frob ${TTY}

or even better (with the very simple action wildcarding i proposed
earlier):

tty0	*		/somewhere/${ACTION}_frob ${TTY}

8-)


I think administration of exactly one file for this sort of thing
makes life... a lot easier, and does not make implementation much
harder at all.


cgd