<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13.333333969116211px;background-color:rgb(255,255,255)">To modify the groups a user is in, you must have administrative access</span></blockquote>
<div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13.333333969116211px;background-color:rgb(255,255,255)">You can u</span><font color="#222222" face="arial, sans-serif">se gpasswd -A to delegate group administration to a non-superuser.</font><div>
<br></div><div>And the main reason of User Private Group (UPG) is that makes it easy to create directories for collaboration.</div><div><br><div class="gmail_quote">2012/10/17 John Moser <span dir="ltr"><<a href="mailto:john.r.moser@gmail.com" target="_blank">john.r.moser@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Oct 17, 2012 at 10:05 AM, Jordon Bedwell <<a href="mailto:jordon@envygeeks.com">jordon@envygeeks.com</a>> wrote:<br>

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