Default group

Alberto Gonzalez darkxer0x at
Wed Oct 17 14:52:25 UTC 2012

> To modify the groups a user is in, you must have administrative access

You can use gpasswd -A to delegate group administration to a non-superuser.

And the main reason of User Private Group (UPG) is that makes it easy to
create directories for collaboration.

2012/10/17 John Moser <john.r.moser at>

> On Wed, Oct 17, 2012 at 10:05 AM, Jordon Bedwell <jordon at>
> wrote:
> >
> > The problem with this is how are you going to fix permissions on bad
> > software like Ruby Gems who do not reset permissions when packaging
> > and uploading to the public repository (because they claim this would
> > "violate security" even though it comes from a public repo like the
> > Debian repo and having public read and execute on a public gem from a
> > public place is "bad".) This has a huge impact as a default permission
> > for not just examples like Ruby gems but other software do not reset
> > when packaging, making it more cumbersome to package software and
> > making it so now work around's are the rule and not the exception.
> Explain the problem more.  The directory the user is in would be owned
> by $USER:users instead of $USER:$USER.  The only difference, then, is
> instead of your stuff being owned by jordon:jordon it's owned by
> jordon:users.
> What you're saying here is... I don't know what you're saying.
> Permissions are currently $USER:users by default with umask=022 and
> $HOME permissions of 755 which means every file is created as:
> drwxr-xr-x jordan:jordan /home/jordan
> drwxr-xr-x jordan:jordan /home/jordan/somedir
> -rwxr--r-- jordan:jordan /home/jordan/somefile
> What I'm suggesting is either umask=022 with a shared 'users' group
> and a default $HOME permission of 700, so
> drwx------ jordan:users /home/jordan
> drwxr-xr-x jordan:users /home/jordan/somedir
> -rwxr--r-- jordan:users /home/jordan/somefile
> In which case if you give the 'users' group or (via extended ACL) any
> other group or person read/execute on /home/jordan they can read
> everything:  they're in 'users' and thus have access to your files,
> just before they couldn't actually reach the inode.  If you give
> 'others' read/execute on /home/jordan then everyone on the system can
> see inside your $HOME, as is the case now.
> ...OR--more risky--a default umask=027 with a shared 'users' group and
> a default $HOME permission of 700, so
> drwx------ jordan:users /home/jordan
> drwxr-x--- jordan:users /home/jordan/somedir
> drwxr----- jordan:users /home/jordan/somefile
> and security is increased, nominally, but honestly not much.  The
> security boost here is files created in shared directories or
> hardlinks created won't let anyone and everyone read those files; the
> truth of the matter is that shouldn't happen, and stuff done in /tmp
> is usually ... temporary, and aware of the security implications.
> More restrictive you could umask=077, but same deal, and then if you
> want to give anyone access to your files you have to change
> permissions the whole way down (which opens up the user to mistakes
> like chmod -R on $HOME and exposing their SSH keys).
> How does putting everyone in the same group and changing $HOME to 0700
> do what you said?
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss at
> Modify settings or unsubscribe at:

The greatest harm can result from the best intentions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Ubuntu-devel-discuss mailing list