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

/etc/group

5 views
Skip to first unread message

bad sector

unread,
Nov 1, 2022, 8:33:30 PM11/1/22
to

there is a method that 'some' distros use consisting of creating a
unique group for every user. The result is that a line in /etc/group
might look like:

userMe:x:1000:

and ownership shown for some file/folder in a file manager might be

owner: userMe
group: userMe

I don't really understand what the advantage of this is but that is not
my point. What I'd like to know is if the line

userMe:x:1000:

(exactly as found in one system) should not be

userMe:x:1000:userMe

given that as it is no user is listed in the group UserMe.

J.O. Aho

unread,
Nov 2, 2022, 2:52:56 AM11/2/22
to
On 02/11/2022 01.33, bad sector wrote:
>
> there is a method that 'some' distros use consisting of creating a
> unique group for every user. The result is that a line in /etc/group
> might look like:
>
> userMe:x:1000:
>
> and ownership shown for some file/folder in a file manager might be
>
> owner: userMe
> group: userMe
>
> I don't really understand what the advantage of this is but that is not
> my point.

It's about user privacy, if all users belongs to the same group, then
all users could have access to each others files, while each user
belonging to different groups makes that a relaxed group privilege will
not give other users access to your files.

What I'd like to know is if the line
>
> userMe:x:1000:
>
> (exactly as found in one system) should not be
>
> userMe:x:1000:userMe


As the users primary group is the group with the same name as the user
name (as seen in /etc/passwd

userMe:x:1000:1000:Me the greatest user of them all:/home/userMe:/bin/ksh

<username>:<password (nowadays in shadows)>:<user id>:<primary group
id>:<description/comment>:<path to home>:<shell>

in group when you have

groupName:x:1001:userMe

it means it's a secondary group the user is part of.


--
//Aho


Richard Kettlewell

unread,
Nov 2, 2022, 4:31:17 AM11/2/22
to
Normally in this setup the user’s default group is the one named for
them, so they don’t need to be listed agaist the group in /etc/groups as
well.

--
http://www.greenend.org.uk/rjk/

Richard Kettlewell

unread,
Nov 2, 2022, 4:45:40 AM11/2/22
to
"J.O. Aho" <us...@example.net> writes:
> On 02/11/2022 01.33, bad sector wrote:
>> there is a method that 'some' distros use consisting of creating a
>> unique group for every user. The result is that a line in /etc/group
>> might look like:
>> userMe:x:1000:
>> and ownership shown for some file/folder in a file manager might be
>> owner: userMe
>> group: userMe
>> I don't really understand what the advantage of this is but that is
>> not my point.
>
> It's about user privacy, if all users belongs to the same group, then
> all users could have access to each others files, while each user
> belonging to different groups makes that a relaxed group privilege
> will not give other users access to your files.

It’s more complicated than that. The thing that controls per-user
(default) privacy settings is the umask. For instance a umask of 077
makes new files be completely private to their owner regardless of how
groups are set up.

The point of per-user groups is to allow umask to be set to make the
shared groups work properly.

* If the umask is 022 or 077 then, when a user creates group files (for
instance, by creating a file in a group directory with the setgid bit)
they’ll lack group read/write permission. The user must chgrp all
shared files before they can be used by other members of the group. A
minor nuisance for the user, and a major nuisance for their
collaborators when they inevitably forget.

* If the umask is 002 or 007 then group files get suitable permissions
automatically. But in this configuration the user’s personal files
would also have group read/write. By giving every user a personal
group which contains only themselves, the group read/write permission
on these files becomes equivalen to owner read/write.

--
http://www.greenend.org.uk/rjk/

J.O. Aho

unread,
Nov 2, 2022, 6:11:30 AM11/2/22
to
On 02/11/2022 09.45, Richard Kettlewell wrote:
> "J.O. Aho" <us...@example.net> writes:
>> On 02/11/2022 01.33, bad sector wrote:
>>> there is a method that 'some' distros use consisting of creating a
>>> unique group for every user. The result is that a line in /etc/group
>>> might look like:
>>> userMe:x:1000:
>>> and ownership shown for some file/folder in a file manager might be
>>> owner: userMe
>>> group: userMe
>>> I don't really understand what the advantage of this is but that is
>>> not my point.
>>
>> It's about user privacy, if all users belongs to the same group, then
>> all users could have access to each others files, while each user
>> belonging to different groups makes that a relaxed group privilege
>> will not give other users access to your files.
>
> It’s more complicated than that. The thing that controls per-user
> (default) privacy settings is the umask. For instance a umask of 077
> makes new files be completely private to their owner regardless of how
> groups are set up.

Sure you can customize umask, but I think the default one is 0022 for
the majority of distributions and those the reasoning behind the privacy
still valid.

--
//Aho

bad sector

unread,
Nov 2, 2022, 7:12:44 AM11/2/22
to
I generally want userMe files/folders to be read/write by userMe and
default 'no-access' by anyone else except root. Suse, a major distro,
never got aboard the bandwagon of user-unique groups if I can call it
that. If I want any file/folder to be accessible by any group I will set
that group and give it perms to something other than interdiction. So
what would be the point of setting one of userMe's folders to userMe read/
write and the userMe (my primary) group to interdicted?

The reason I'm asking is that running 7 distros I'm always looking for
commonality if possible: in theory all /etc/group and /etc/passwd links
in all systems to point to singular real files on a data drive.

Richard Kettlewell

unread,
Nov 2, 2022, 11:02:46 AM11/2/22
to
If umask is 022 then most new files will be world readable, and having
per-user groups makes no difference to that. The purpose is as I said;
they do not add any privacy if umask=022.

--
http://www.greenend.org.uk/rjk/

Richard Kettlewell

unread,
Nov 2, 2022, 11:04:29 AM11/2/22
to
bad sector <forg...@invalid.org> writes:
> I generally want userMe files/folders to be read/write by userMe and
> default 'no-access' by anyone else except root.

You want umask 077 then.

--
http://www.greenend.org.uk/rjk/

Bit Twister

unread,
Nov 27, 2022, 11:43:52 AM11/27/22
to
On Wed, 02 Nov 2022 11:12:37 +0000, bad sector wrote:

> I generally want userMe files/folders to be read/write by userMe and
> default 'no-access' by anyone else except root. Suse, a major distro,
> never got aboard the bandwagon of user-unique groups if I can call it
> that. If I want any file/folder to be accessible by any group I will set
> that group and give it perms to something other than interdiction. So
> what would be the point of setting one of userMe's folders to userMe read/
> write and the userMe (my primary) group to interdicted?
>
> The reason I'm asking is that running 7 distros I'm always looking for
> commonality if possible: in theory all /etc/group and /etc/passwd links
> in all systems to point to singular real files on a data drive.

I too run a multi-boot setup and have three nodes on my lan.
The first time systemd started moving new users to 1000, I went in
and moved all user uid/gid to id +1500. That allowed to script the
saving/restoring UID/GID pretty simple.

I have a /accounts partition where user files are shared across boots,
because /home is not shared. I have install_links script that reads
/accounts/$USER and creates links in $HOME for the shared/common files
and directories.

My install scripts creates common ID/GID for the shared IDs.


0 new messages