> Date: Fri, 19 Apr 1996 17:00:32 -0400
> From: Chris G Demetriou <Chris_G_Demetriou@UX2.SP.CS.CMU.EDU>
> 
> > > % 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?

Let me restate that.  I should have said "After a new login, the tty
and all related devices should be owned by the user, group set to
[some constant value sensible for that device type] and mode=0600."
I'd like to follow the model used for the tty device;  Once you're
logged in, you own the device and can do what you want with it.

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

Would it not accomplish the same end to chown the device?
If you want them to have exclusive access, set mode=0600.
If not, choose a useful (probably constant) group and mode
and apply those the device in addition to doing the chown.

I haven't yet heard of any case where you need to set the group
of some device to the groupid of the new login, assuming you will
always chown "related" devices to the UID of the new login.

> 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()...

... which has to scan the group database to get it...
I was hoping to avoid that.  I still don't see the need.

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

Exactly.  If you really need it, then you pay the price to get it.

> > 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.

True, and as I see it, they don't have to do anything even if
you start them off with all their devices having some constant
groupid (whatever is normal for that device type).  You could
certainly get fancy in your shell_command if you wanted anyway.

> > 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.

The parsing is not a problem.  I was referring to the proposal
(not quoted above) to have "chown" and "chmod" actions and such
in addition to "login" and "logout" actions (to avoid having to
fork a shell for those).

I'm coming to like the idea of a single file where the 2nd field
is a "match criteria" just like the first field (tty_name).  I'm
not as comfortable with the idea of a long list of "action verbs"
being supported in the 2nd field.  That sounds like bloat to me.
(Trying to make this into a shell! 8^)

> 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.

Sure, one file is nice, and not much harder.

> or even better (with the very simple action wildcarding i proposed
> earlier):
> 
> tty0	*		/somewhere/${ACTION}_frob ${TTY}

Maybe that should be "any" instead of "*" in case we decide to add
some kind of globbing or regular expression support later.

Gordon