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.mo...@gmail.com
On Wed, Oct 17, 2012 at 10:05 AM, Jordon Bedwell jor...@envygeeks.com
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@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
--
-
The greatest harm can result from the best intentions
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
