lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Multiuser *nix configuration


From: Vadim Zeitlin
Subject: Re: [lmi] Multiuser *nix configuration
Date: Sat, 2 May 2020 00:26:44 +0200

On Fri, 1 May 2020 21:14:42 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2020-05-01 16:31, Vadim Zeitlin wrote:
GC> > On Fri, 1 May 2020 16:09:31 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> Vadim--Is there any reason not to do the following on our
GC> > GC> linux server?
GC> > GC>  - umask 002
GC> > 
GC> >  Yes, this seems reasonable, especially if each user still has their own
GC> > group (instead of just being part of some "users" group, but I think all
GC> > Linux distributions now create per-user group by default),
GC> 
GC> Unfortunately, no, we're all part of some "users" group.

 Just to be clear: it's fine to be member of the same "users" group as long
as you're also member of your own unique user group, to which your home
belongs. If there is no such group, and home belongs to user group, this is
not ideal, as other members of the same group would be able to read/write
files in your home directory. This would definitely be unacceptable on a
normal multiuser system (just too much potential for abuse...) but could
still be fine for this closed/dedicated system, I guess.

GC> > and so files
GC> > under their home remain only writable by them and not by everybody.
GC> 
GC> Below, I discuss a workaround that would achieve that result.

 Yes, this was similar to what I was going to suggest...

GC> This works:
GC> 
GC> https://lists.nongnu.org/archive/html/lmi/2019-09/msg00022.html
GC> |  # Set up an 'lmi' group...
GC> |  sudo groupadd lmi
GC> |  # for U = my id and U = Kim's id both:
GC> |  sudo usermod -a -G lmi ${U}
GC> 
GC> and seems to affect only /etc/group , but this fails:
GC> 
GC>   $sudo usermod -g lmi my_secret_id
GC>   usermod: user '...' does not exist in /etc/passwd
GC> 
GC> Although I can't change my primary group permanently,
GC> I can change it temporarily:
GC> 
GC>   $newgrp lmi
GC>   $id -gn
GC>   lmi
GC> 
GC> so maybe we should do that in ~/.zshrc .

 I'd rather newgrp/sg to your private group instead. Normally it's not a
problem that lmi is not your primary group as long as you use SGID bit on
the shared directories anyhow, as it's this bit (i.e. the group of the
directory) that will determine the group of the new entries in it.

GC> As for making /home/my_user readable by me only, I could
GC>   $sudo groupadd special_group_for_me_only
GC>   $sudo usermod -a -G special_group_for_me_only
GC> and then Kim couldn't read it, except with sudo.

 Yes. And this could be useful, and not because only of the issues of
trust, but also because it would detect any bugs in your scripts that would
accidentally write to the wrong directory, for example, whereas currently
this would go unnoticed.

GC> But I hesitate to do this, because something bad might
GC> happen to my home directory if corporate IT removes my
GC> special group.

 But this is a valid consideration that I didn't think about... I guess you
could still have ~/real-home directory owned by your-secret-group and do
"HOME=~/real-home exec -l sg your-secret-group /usr/bin/zsh" after logging
in manually.

 Regards,
VZ

Attachment: pgpeoJzWGjOdm.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]