Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

About shells and groups

20 views
Skip to first unread message

Harold Johanssen

unread,
Sep 8, 2017, 9:55:18 AM9/8/17
to
A Unix system (any flavor) has a user which is defined as
belonging to a set of groups G. Somebody logs in as U by means of SSH,
and interactive shell S1 is created for U. It is obvious that S1 will
enjoy the privileges afforded by the set of groups G.

With S1 still active, from a totally separate and independent
shell the superuser changes G into G' for U, with G' being more
restrictive than G - essentially, G' being a subset of G. Thus, if a new
shell S2 is created for U, it will enjoy the more limited set of
privileges embodied in G'.

My question is, what happens to S1? Do its privileges remain, or
do they become curtailed by the fact the U now belongs to the set of
groups G', rather G? Does the resulting behavior, whatever it is, depend
on the type of shell? Or on anything else, for that matter? Or is it the
case that, once a shell has been spawned, it retains membership,
throughout its life, to the groups that it was assigned to in /etc/groups
at the time when the shell was spawned?

Casper H.S. Dik

unread,
Sep 8, 2017, 10:04:03 AM9/8/17
to
Harold Johanssen <noe...@please.net> writes:

> My question is, what happens to S1? Do its privileges remain, or
>do they become curtailed by the fact the U now belongs to the set of
>groups G', rather G? Does the resulting behavior, whatever it is, depend
>on the type of shell? Or on anything else, for that matter? Or is it the
>case that, once a shell has been spawned, it retains membership,
>throughout its life, to the groups that it was assigned to in /etc/groups
>at the time when the shell was spawned?

The original shell will still have the original set of groups. That will
nog change and all of the new children of that shell will still have
the exact same groups.

Casper

Barry Margolin

unread,
Sep 8, 2017, 11:39:00 AM9/8/17
to
In article <59b2a34c$0$825$e4fe...@news.xs4all.nl>,
And to be more specific, groups aren't set when a shell (or any other
process) is spawned. They're set specifically by the login process, and
inherited by all descendant processes (unless a process takes explicit
action to update its groups).

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Ivan Shmakov

unread,
Sep 8, 2017, 12:15:48 PM9/8/17
to
>>>>> Barry Margolin <bar...@alum.mit.edu> writes:
>>>>> Casper H.S. Dik <Caspe...@OrSPaMcle.COM> wrote:
>>>>> Harold Johanssen <noe...@please.net> writes:

>>> My question is, what happens to S1? Do its privileges remain, or
>>> do they become curtailed by the fact the U now belongs to the set
>>> of groups G', rather G? Does the resulting behavior, whatever it
>>> is, depend on the type of shell? Or on anything else, for that
>>> matter? Or is it the case that, once a shell has been spawned, it
>>> retains membership, throughout its life, to the groups that it was
>>> assigned to in /etc/groups at the time when the shell was spawned?

>> The original shell will still have the original set of groups. That
>> will nog change and all of the new children of that shell will still
>> have the exact same groups.

Also, unless a specific restriction is placed, it's possible for
the user to create an SGID wrapper and effectively retain
membership in the group "indefinitely"; say:

$ cp -i -- "$SHELL" ~/bin/mysh
$ chgrp -- grp ~/bin/mysh
$ chmod -- g+s ~/bin/mysh
$

> And to be more specific, groups aren't set when a shell (or any other
> process) is spawned. They're set specifically by the login process,
> and inherited by all descendant processes (unless a process takes
> explicit action to update its groups).

And that's the reason I advise against using groups to grant
privileges except for the most "static" of cases. (E. g., I see
nothing wrong with adding the user account of the system's owner
to 'adm' or 'audio' groups.)

In all the other cases, one should use either a "privilege
gateway" program (like sudo(8) in the simpler cases),
or chacl(1); like:

$ chacl u::rw-,g::rw-,o::---,m::rw-,u:joe:rw- -- /dev/cdrom ; ## grant access
$ chacl u::rw-,g::rw-,o::--- -- /dev/cdrom ; ## revoke access

--
FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A

Harold Johanssen

unread,
Sep 8, 2017, 12:41:34 PM9/8/17
to
Thank you all for your very enlightening feedback.

0 new messages