> > 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
