Re: Default group
So, nobody agree the idea of a smart sharing app'? 2012/10/18 Nicolas Michel be.nicolas.mic...@gmail.com 2012/10/18 Jordon Bedwell jor...@envygeeks.com On Thu, Oct 18, 2012 at 4:31 AM, Nicolas Michel be.nicolas.mic...@gmail.com wrote: To be honnest I never gave a try to Ubuntu One, probably for bad conservative reasons. I will try it. But I still feel that even if you're right that pushing things into the cloud make things simpler, there are still some flaws : Most of these flaws are always subjective, except when it comes to security, since UbuntuOne still does not have encryption (from last I heard) it's not a viable solution for people who need to backup secure documents, and it comes at a cost too since AmazonS3 now supports built-in encryption without the need of a 3rd party source. It comes at even more of a cost when people realize that s3fs is not hard to use at all. I don't know why Canonical or Ubuntu or whoever owns it does not see these problems but whatever, I'm not their CTO. - what if we don't have access to internet and only want to share on the Then you share the folder via LAN while still allowing UbuntuOne to Sync. Ubuntu does not prevent you from accessing the folder at all, or doing what you want with it, except renaming it, you do have to play a little bit of filesystem trickery to rename it as a normal user. At the base it's a thread about sharing content. So I know that using Ubuntu One doesn't prevent me to share the same content also with Samba or something else. But my previous mail was talking about a simple app to auto-configure sharing and choosing the best me in function of the purpose and location of user A and B. - what with DLNA ? Are users needs to be technical guys to be able to use. What has DLNA got to do with normal file storage? It's not content hosting. Unless they started with it recently and went CDN which would be pretty amazing considering they have no support for things like the WD Live, Sony/Samsung/LG Blueray or others but a quick Google search suggests they are not a content provider. A user don't care about a technical word definition: I agree that DLNA is not content hosting. But when a user want to share, maybe it means that the best solution for what he wants to do is DLNA? - of course I think about the speed. To come-back on my earlier exemple in a gaming LAN : what if I want to share some Gigs of data to others in the same LAN? It can't be done through Ubuntu One I guess? Although technical solutions exists to do it (and really the most simple seems to me webdav - a pretty good solution I think but until now it's usage never really took-off). Speed is more or less on your end, That's the point. If I want to share to a point A to B, maybe that it will be really much faster to share the content in webdav or samba than with Ubuntu One. if Canonical is smart they will geo-host via AWS (that is unless they build their own infrastructure then you would hope they still zone.) If they are on AWS they have access to a pipes bigger by 10x if not more than anything you could get for less than 10-50K (1-50K realistically depending on the type of servers they get) a month unless you are in KC (or North California) and manage to convince Google to make your area a Fibrehood. Nobody is stopping you from sharing gigs of data though. If you are suggesting using it for storing games and what-have-you so called live-data then that's on you because no storage service like Ubuntu one is designed for that sort of thing, that requires an entirely different stack design, one that thinks about what happens between point a and point b and not one that only wants you to make it to point b. People often assume that servers are the same, they are not. Generally, I don't say Ubuntu One is not a good thing. I think it is part of the solution but not all the solution by itself. That's why I was talking about a kind of app wrapper to help people sharing the best way to serve their purpose. -- Nicolas MICHEL -- Nicolas MICHEL -- 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
Re: Default group
I agree that there should be something done on the UI to support ACL on Ubuntu (not like eiciel). But I really don't agree when you say that Windows is already doing it well! Honnestly, nobody never understood these pretty technical concepts of permissions (I mean usual end-users, not us that are talking on a dev linux distrib mailing-list). I still organize some gaming LAN with friends (on Windows of course ...) and most of the time, when someone want to share something, they prefer : - copy their things to an external DD - give the external DD to their friend - the friend then copy the content on his local disk Although they're all connected to a gigabit switch, using the external disk is not the fastest but it's the simpler. I already explained how to make a network share but it involved too much computer skills : IP, filesystem, permissions, network share... So they continue to use their external disk. I don't even try to explain it anymore ;) Conclusion: instead of creating an UI that just reflects the low level understanding of ACL which won't help the majority of peoples we need something better. In a UI, things needs to be astracted. So we should think about sharing as a Service like in SAAS: you really don't know which technical configuration is involved but it works. So I think that a sharing options should launch a wizard wich ask simple questions that do not involve any technical skills (but with some hints for technical guys) like : 1) to who do you want to share the directory: a: another user on this computer b: another computer on my local network (LAN) (#maybe that using something like webdav would be simpler than Samba or NFS?) c: someone which is connected to internet like me (# and then using something in the cloud like Ubuntu One?) 2) Is the other user can delete and modify the content or only see it? The wizard do whatever needed for it to work : modify filesystem permissions, configure a Samba Share, or a Webdav service ... At the end of the wizard, it tells the instructions to give to the other guy how to access the share (give an url and saying to type it in their internet browser, a path and saying how to use it...). To go further, I think sharing should even not be implemented into nautilus or other file browser! It should be something standalone with a shortcut in the dash, which opens a windows like the system configuration one with some icons like : - see my current shares - create a new share - connect to a share that someone gave me What do you think? Nicolas 2012/10/18 John Moser john.r.mo...@gmail.com On 10/17/2012 06:43 PM, Marc Deslauriers wrote: On 12-10-17 05:45 PM, John Moser wrote: On 10/17/2012 05:34 PM, Marc Deslauriers wrote: On 12-10-17 03:52 PM, John Moser wrote: First, he must find the sysadmin. The sysadmin must then put wriker in group jkirk. Also, ~jkirk must be group-readable, as must any files. In a default Ubuntu installation, jkirk's files are already accessible to other users. Yeah I just looked and saw that, my whole $HOME is world-readable. This displeases me. I'd prefer default $HOME chmod 700. As I said, we wanted people to be able to share files by default without having to understand granting permissions. This has already been discussed to death, although it's been a while. It's good to revisit things. I'm bringing up what's turning into an evolving alternate proposal, at this point I've gotten as far out as suggesting UI changes and a sticky bit (= /tmp) directory acting as a Shared Documents between users, which I'm guessing didn't come up last round. Sometimes the rules change. Of course, you're absolutely right. I'm not sure what I was thinking there for a sec. :P Wrong facility probably. Changing permission != changing group, which is what this discussion started on. I'm not sure this proposal would be simple enough to be understood by most non-technical users. Also, last time we looked at using extended attributes, there were issues with proper support in common tools, backup software, certain filesystems, etc. This would need to be looked at again to see if extended attributes can be used now. It's certainly worth investigating it again. I may as well continue beating the Look at Windows horse, it's done this right for ages anyway. You should consider your user base though: they've already installed Ubuntu. Most of them. Some probably got a tablet or such that came with it, but single-user systems likely do not care. We're talking about shared multi-user systems where everyone isn't admin, which is kind of a narrow case. That's less most users don't need to know how and more most users won't be faced by a sudden, surprising, confusing change (like moving from Gnome2 to Ubiquity or Gnome3 by default?). In other words, I suspect most users aren't particularly attached to the sharing my files with everyone else case. Finally on that discussion, the
Re: Default group
I think that the wizard should also be smart enough to asks questions related to the content to share. Example, if you want to share a video or an audio file, maybe it's best to share it via DLNA if the viewer is on the same LAN. Then it needs to ask a question like : - do you want to share the video/audio in the purpose of the other user to play it in a multimedia player? (DLNA) - do you want to share the video/audio so the other user can copy it on its computer? (File sharing) As explains in my previous mail, the option connect to a share that someone gave me would only be a wrapper that understand the URI we gave to it : DLNA, Samba, Webdav, NFS ... I also think that if wizards is really what usual users need, as a technical guys I often find them limitating because of their abstractions, I need to think what the dev wanted to say (technically speaking). For example, if I know what is DLNA and that I want to share a media via DLNA, using traditionnal tool takes some times to make it working, and using the mentionned wizard will need me to choose the right answers to be able to make a DLNA sharing. So I think that: 1) there should be a first question like : - I'm a technical guy and I know what I want - I only want to share something and the how is not of my interest (then it doesn't opens a new windows but only change the sets of questions the wizard will ask) : you could also add a check box remember my choice for further same action. 2) whatever you choose at start (technical guy) you should have a 2 columns window. On the biggest one on the left : the QA. On the little column on the right, a technical recap of what technical solution will be used, related to the questions answered. You should be able to click on links there to change configuration manually (despite the answers given). Usual users won't take care of it. Technical guys will understand what the wizard will really do. That's transparency. So the concept is that there should be a kind a model of a share : something with some fields to configure: - what to share : filesystem path to the item to share - kind of share : dlna, samba, nfs, webdav, ubuntu one ... - permissions that will be modified: which permissions on which level (filesystem? sharing service? ...) The purpose of the QA is only to complete that model. So the last step of the wizard that will configure everything will only have to take care of that profile. And so the QA can be changed/adapted easily through versions of the app without having to rewrite the code that really do the things. 2012/10/18 Nicolas Michel be.nicolas.mic...@gmail.com I agree that there should be something done on the UI to support ACL on Ubuntu (not like eiciel). But I really don't agree when you say that Windows is already doing it well! Honnestly, nobody never understood these pretty technical concepts of permissions (I mean usual end-users, not us that are talking on a dev linux distrib mailing-list). I still organize some gaming LAN with friends (on Windows of course ...) and most of the time, when someone want to share something, they prefer : - copy their things to an external DD - give the external DD to their friend - the friend then copy the content on his local disk Although they're all connected to a gigabit switch, using the external disk is not the fastest but it's the simpler. I already explained how to make a network share but it involved too much computer skills : IP, filesystem, permissions, network share... So they continue to use their external disk. I don't even try to explain it anymore ;) Conclusion: instead of creating an UI that just reflects the low level understanding of ACL which won't help the majority of peoples we need something better. In a UI, things needs to be astracted. So we should think about sharing as a Service like in SAAS: you really don't know which technical configuration is involved but it works. So I think that a sharing options should launch a wizard wich ask simple questions that do not involve any technical skills (but with some hints for technical guys) like : 1) to who do you want to share the directory: a: another user on this computer b: another computer on my local network (LAN) (#maybe that using something like webdav would be simpler than Samba or NFS?) c: someone which is connected to internet like me (# and then using something in the cloud like Ubuntu One?) 2) Is the other user can delete and modify the content or only see it? The wizard do whatever needed for it to work : modify filesystem permissions, configure a Samba Share, or a Webdav service ... At the end of the wizard, it tells the instructions to give to the other guy how to access the share (give an url and saying to type it in their internet browser, a path and saying how to use it...). To go further, I think sharing should even not be implemented into nautilus or other file browser! It should be something standalone with a shortcut in
Re: Default group
Nicolas Michel be.nicolas.mic...@gmail.com writes: Honnestly, nobody never understood these pretty technical concepts of permissions (I mean usual end-users, not us that are talking on a dev linux distrib mailing-list). +1 snip/ To go further, I think sharing should even not be implemented into nautilus or other file browser! +1 It should be something standalone with a shortcut in the dash, which opens a windows like the system configuration one with some icons like : - see my current shares - create a new share - connect to a share that someone gave me Sounds like something already implemented in ubuntu one to me ;) In a nutshell: people don't understand permissions and their fallouts. It's simpler to have home directories and their content private (or even encrypted) and define shares in a special place. I can think of only two kinds of share to be honest: - I have write access and nobody else, - I and others have write access. And even that is not that simple when you start wanting to access them off-line. This has been the case for decades and no OS I know of ever come close to a flawless solutions until we started to use the cloud for sharing at which point OSes and their incompatible permission schemes became irrelevant. Vincent -- 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
Re: Default group
To be honnest I never gave a try to Ubuntu One, probably for bad conservative reasons. I will try it. But I still feel that even if you're right that pushing things into the cloud make things simpler, there are still some flaws : - what if we don't have access to internet and only want to share on the LAN? - what with DLNA ? Are users needs to be technical guys to be able to use it? - of course I think about the speed. To come-back on my earlier exemple in a gaming LAN : what if I want to share some Gigs of data to others in the same LAN? It can't be done through Ubuntu One I guess? Although technical solutions exists to do it (and really the most simple seems to me webdav - a pretty good solution I think but until now it's usage never really took-off). Regards, Nicolas 2012/10/18 Vincent Ladeuil vila+...@canonical.com Nicolas Michel be.nicolas.mic...@gmail.com writes: Honnestly, nobody never understood these pretty technical concepts of permissions (I mean usual end-users, not us that are talking on a dev linux distrib mailing-list). +1 snip/ To go further, I think sharing should even not be implemented into nautilus or other file browser! +1 It should be something standalone with a shortcut in the dash, which opens a windows like the system configuration one with some icons like : - see my current shares - create a new share - connect to a share that someone gave me Sounds like something already implemented in ubuntu one to me ;) In a nutshell: people don't understand permissions and their fallouts. It's simpler to have home directories and their content private (or even encrypted) and define shares in a special place. I can think of only two kinds of share to be honest: - I have write access and nobody else, - I and others have write access. And even that is not that simple when you start wanting to access them off-line. This has been the case for decades and no OS I know of ever come close to a flawless solutions until we started to use the cloud for sharing at which point OSes and their incompatible permission schemes became irrelevant. Vincent -- Nicolas MICHEL -- 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
Re: Default group
On Thu, Oct 18, 2012 at 4:31 AM, Nicolas Michel be.nicolas.mic...@gmail.com wrote: To be honnest I never gave a try to Ubuntu One, probably for bad conservative reasons. I will try it. But I still feel that even if you're right that pushing things into the cloud make things simpler, there are still some flaws : Most of these flaws are always subjective, except when it comes to security, since UbuntuOne still does not have encryption (from last I heard) it's not a viable solution for people who need to backup secure documents, and it comes at a cost too since AmazonS3 now supports built-in encryption without the need of a 3rd party source. It comes at even more of a cost when people realize that s3fs is not hard to use at all. I don't know why Canonical or Ubuntu or whoever owns it does not see these problems but whatever, I'm not their CTO. - what if we don't have access to internet and only want to share on the Then you share the folder via LAN while still allowing UbuntuOne to Sync. Ubuntu does not prevent you from accessing the folder at all, or doing what you want with it, except renaming it, you do have to play a little bit of filesystem trickery to rename it as a normal user. - what with DLNA ? Are users needs to be technical guys to be able to use. What has DLNA got to do with normal file storage? It's not content hosting. Unless they started with it recently and went CDN which would be pretty amazing considering they have no support for things like the WD Live, Sony/Samsung/LG Blueray or others but a quick Google search suggests they are not a content provider. - of course I think about the speed. To come-back on my earlier exemple in a gaming LAN : what if I want to share some Gigs of data to others in the same LAN? It can't be done through Ubuntu One I guess? Although technical solutions exists to do it (and really the most simple seems to me webdav - a pretty good solution I think but until now it's usage never really took-off). Speed is more or less on your end, if Canonical is smart they will geo-host via AWS (that is unless they build their own infrastructure then you would hope they still zone.) If they are on AWS they have access to a pipes bigger by 10x if not more than anything you could get for less than 10-50K (1-50K realistically depending on the type of servers they get) a month unless you are in KC (or North California) and manage to convince Google to make your area a Fibrehood. Nobody is stopping you from sharing gigs of data though. If you are suggesting using it for storing games and what-have-you so called live-data then that's on you because no storage service like Ubuntu one is designed for that sort of thing, that requires an entirely different stack design, one that thinks about what happens between point a and point b and not one that only wants you to make it to point b. People often assume that servers are the same, they are not. -- 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
Re: Default group
2012/10/18 Jordon Bedwell jor...@envygeeks.com On Thu, Oct 18, 2012 at 4:31 AM, Nicolas Michel be.nicolas.mic...@gmail.com wrote: To be honnest I never gave a try to Ubuntu One, probably for bad conservative reasons. I will try it. But I still feel that even if you're right that pushing things into the cloud make things simpler, there are still some flaws : Most of these flaws are always subjective, except when it comes to security, since UbuntuOne still does not have encryption (from last I heard) it's not a viable solution for people who need to backup secure documents, and it comes at a cost too since AmazonS3 now supports built-in encryption without the need of a 3rd party source. It comes at even more of a cost when people realize that s3fs is not hard to use at all. I don't know why Canonical or Ubuntu or whoever owns it does not see these problems but whatever, I'm not their CTO. - what if we don't have access to internet and only want to share on the Then you share the folder via LAN while still allowing UbuntuOne to Sync. Ubuntu does not prevent you from accessing the folder at all, or doing what you want with it, except renaming it, you do have to play a little bit of filesystem trickery to rename it as a normal user. At the base it's a thread about sharing content. So I know that using Ubuntu One doesn't prevent me to share the same content also with Samba or something else. But my previous mail was talking about a simple app to auto-configure sharing and choosing the best me in function of the purpose and location of user A and B. - what with DLNA ? Are users needs to be technical guys to be able to use. What has DLNA got to do with normal file storage? It's not content hosting. Unless they started with it recently and went CDN which would be pretty amazing considering they have no support for things like the WD Live, Sony/Samsung/LG Blueray or others but a quick Google search suggests they are not a content provider. A user don't care about a technical word definition: I agree that DLNA is not content hosting. But when a user want to share, maybe it means that the best solution for what he wants to do is DLNA? - of course I think about the speed. To come-back on my earlier exemple in a gaming LAN : what if I want to share some Gigs of data to others in the same LAN? It can't be done through Ubuntu One I guess? Although technical solutions exists to do it (and really the most simple seems to me webdav - a pretty good solution I think but until now it's usage never really took-off). Speed is more or less on your end, That's the point. If I want to share to a point A to B, maybe that it will be really much faster to share the content in webdav or samba than with Ubuntu One. if Canonical is smart they will geo-host via AWS (that is unless they build their own infrastructure then you would hope they still zone.) If they are on AWS they have access to a pipes bigger by 10x if not more than anything you could get for less than 10-50K (1-50K realistically depending on the type of servers they get) a month unless you are in KC (or North California) and manage to convince Google to make your area a Fibrehood. Nobody is stopping you from sharing gigs of data though. If you are suggesting using it for storing games and what-have-you so called live-data then that's on you because no storage service like Ubuntu one is designed for that sort of thing, that requires an entirely different stack design, one that thinks about what happens between point a and point b and not one that only wants you to make it to point b. People often assume that servers are the same, they are not. Generally, I don't say Ubuntu One is not a good thing. I think it is part of the solution but not all the solution by itself. That's why I was talking about a kind of app wrapper to help people sharing the best way to serve their purpose. -- Nicolas MICHEL -- 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
Re: Default group
On Wed, Oct 17, 2012 at 8:59 AM, John Moser john.r.mo...@gmail.com wrote: I suggest all users should go into group 'users' as the default group, with $HOME default to 700 and in the group 'users'. A umask of 027 or the traditional 022 is still viable: the files in $HOME are not visible because you cannot list the contents of $HOME (not readable) or change into it to access the files within (not executable). A user can grant permissions to other users to access his files simply by making the directory readable by them--by 'users' or others (thus everyone) or by fine-grained POSIX ACLs selecting for individual users and groups. 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. -- 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
Re: Default group
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
Re: Default group
On 12-10-17 09:59 AM, John Moser wrote: I suggest all users should go into group 'users' as the default group, with $HOME default to 700 and in the group 'users'. A umask of 027 or the traditional 022 is still viable: the files in $HOME are not visible because you cannot list the contents of $HOME (not readable) or change into it to access the files within (not executable). A user can grant permissions to other users to access his files simply by making the directory readable by them--by 'users' or others (thus everyone) or by fine-grained POSIX ACLs selecting for individual users and groups. We want users to be able to share files with other users. Having $HOME be 700 defeats that purpose. See: https://wiki.ubuntu.com/SecurityTeam/Policies#Permissive_Home_Directory_Access Also, one of the reasons for using User Private Groups, is to be able to create directories that are used by multiple users, by setting the setgid on the directory. With a default umask of 022, users need to manually set group permissions each time they create a file. Marc. -- Marc Deslauriers Ubuntu Security Engineer | http://www.ubuntu.com/ Canonical Ltd. | http://www.canonical.com/ -- 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
Re: Default group
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
Re: Default group
On Wed, Oct 17, 2012 at 10:44 AM, Marc Deslauriers marc.deslauri...@canonical.com wrote: On 12-10-17 09:59 AM, John Moser wrote: I suggest all users should go into group 'users' as the default group, with $HOME default to 700 and in the group 'users'. A umask of 027 or the traditional 022 is still viable: the files in $HOME are not visible because you cannot list the contents of $HOME (not readable) or change into it to access the files within (not executable). A user can grant permissions to other users to access his files simply by making the directory readable by them--by 'users' or others (thus everyone) or by fine-grained POSIX ACLs selecting for individual users and groups. We want users to be able to share files with other users. Having $HOME be 700 defeats that purpose. See: https://wiki.ubuntu.com/SecurityTeam/Policies#Permissive_Home_Directory_Access Which, as I said, is accomplished by adding the user or an appropriate group to the Extended ACL of $HOME, as the umask is still permissive and the files are all owned by a common user group. It can also be blanket accomplished by adding read access to group or others on $HOME, which would return the system to effectively as it is now. Also, one of the reasons for using User Private Groups, is to be able to create directories that are used by multiple users, by setting the setgid on the directory. With a default umask of 022, users need to manually set group permissions each time they create a file. Setting setgid on the directory to allow multiple users to add files to it still requires that the users be in the group or that the directory be world-writable. The proper way to accomplish this is, again, to place the directory into the shared 'users' group and grant individual user or group access via ACLs, rather than a shotgun approach by which either the directory is either world-writable or the users have to be put into some other user's group and then suddenly have blanket access to that user's files unless he tightens down permissions on his $HOME. setgid would also do ... just about nothing, since without setUID on the directory the file's permissions are still g-w. Although some Googling is telling me that Ubuntu changed the default umask to 002 back in Oneric, so apparently yeah this works, caveat above paragraph. In short, the current method is a lot of this works... with a lot of unintended consequences. Marc. -- Marc Deslauriers Ubuntu Security Engineer | http://www.ubuntu.com/ Canonical Ltd. | http://www.canonical.com/ -- 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 -- 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
Re: Default group
John, Do you know KISS http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond ? So ACL works well. But it's really more complicated to use than UGO and surely to understand who has which access to what. Trust me it can be really hard to get it with complex configurations. So I would say : why use a complex solution for a simple need? Regards, Nicolas 2012/10/17 John Moser john.r.mo...@gmail.com On Wed, Oct 17, 2012 at 10:44 AM, Marc Deslauriers marc.deslauri...@canonical.com wrote: On 12-10-17 09:59 AM, John Moser wrote: I suggest all users should go into group 'users' as the default group, with $HOME default to 700 and in the group 'users'. A umask of 027 or the traditional 022 is still viable: the files in $HOME are not visible because you cannot list the contents of $HOME (not readable) or change into it to access the files within (not executable). A user can grant permissions to other users to access his files simply by making the directory readable by them--by 'users' or others (thus everyone) or by fine-grained POSIX ACLs selecting for individual users and groups. We want users to be able to share files with other users. Having $HOME be 700 defeats that purpose. See: https://wiki.ubuntu.com/SecurityTeam/Policies#Permissive_Home_Directory_Access Which, as I said, is accomplished by adding the user or an appropriate group to the Extended ACL of $HOME, as the umask is still permissive and the files are all owned by a common user group. It can also be blanket accomplished by adding read access to group or others on $HOME, which would return the system to effectively as it is now. Also, one of the reasons for using User Private Groups, is to be able to create directories that are used by multiple users, by setting the setgid on the directory. With a default umask of 022, users need to manually set group permissions each time they create a file. Setting setgid on the directory to allow multiple users to add files to it still requires that the users be in the group or that the directory be world-writable. The proper way to accomplish this is, again, to place the directory into the shared 'users' group and grant individual user or group access via ACLs, rather than a shotgun approach by which either the directory is either world-writable or the users have to be put into some other user's group and then suddenly have blanket access to that user's files unless he tightens down permissions on his $HOME. setgid would also do ... just about nothing, since without setUID on the directory the file's permissions are still g-w. Although some Googling is telling me that Ubuntu changed the default umask to 002 back in Oneric, so apparently yeah this works, caveat above paragraph. In short, the current method is a lot of this works... with a lot of unintended consequences. Marc. -- Marc Deslauriers Ubuntu Security Engineer | http://www.ubuntu.com/ Canonical Ltd. | http://www.canonical.com/ -- 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 -- 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 -- Nicolas MICHEL -- 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
Re: Default group
First: that's why we need an interface that handles POSIX ACLs properly, long-overdue. Second, this is not simple. This is a recommendation to use shotgun approach to everything and leave gaping holes because it's convenient. I don't mean to say this is a critical 100% immediate security hole; I mean that trying to carefully, craftily use the current scheme is very complex. Let's first assume we have three users: jkirk ksingh wriker Now, let's say any of these wants to give any of the others access to his files in general (i.e. his $HOME). Let's for our example say jkirk wants wriker to have access. First, he must find the sysadmin. The sysadmin must then put wriker in group jkirk. Also, ~jkirk must be group-readable, as must any files. To do this without a sysadmin, the user must be sysadmin. Either none or one of these users can do it all; or all of them can and then we're not dealing with any kind of document security. With POSIX ACL instead AND AN INTERFACE FOR IT, jkirk simply right-clicks on his Home directory in Nautilus (Konqueror Thunar etc), hits Permissions, Add, puts in 'wriker' with 'read, access files inside directory'. Since his files are all read-write by group (umask=002) instead of just readable (umask=022), this makes all his files writable by wriker, of course. That's not the point here, HOWEVER it is a concern. Notice this is simple, and the user can do it themselves. Someone raised shared directories and SGID. When we get to SGID we've stepped slightly outside simple, but I'll allow it. Let's say now jkirk wants to share specific files with wriker, and specific other files with ksingh. Let's tackle ksingh first. jkirk could put a directory in a shared location, with SGID, accessible by jkirk, and have the sysadmin give ksingh the jkirk group. This would, of course, also allow ksingh into anything else accessible by jkirk's group--so if his home directory is open, or if he has a file shared with wriker by putting wriker in the jkirk group, those files are also accessible by ksingh as a matter of course. Repeat: those OTHER files are also accessible by ksingh as a matter of course. Instead, ksingh could have jkirk put in the ksingh group; this creates the same problem for ksingh. Next of course jkirk tries to create a shared directory to share some files with wriker, but of course that makes things complex. Maybe wriker does it, but then he shares with ksingh, which means wriker has the same problem of jkirk getting files he wants to only share with ksingh, or jkirk must accept the problem of sharing files with ksingh when he only wants those files to go to wriker (and with wriker when he wants those files only to go to ksingh). Then, everybody gives up and just uses e-mail to send files back and forth. Instead, jkirk creates a directory to share with ksingh. The directory is mode 700, owned by jkirk, and in the group 'users', and with the SGID bit set (so not mode 700, more mode 02700? I forget what's SUID, SGID, and sticky, ok?). He right clicks on it, hits Properties, Permissions, adds ksingh with rwx (remember X on directories is access files inside). When jkirk or ksingh creates files inside, they are read/write by group and automatically in the group 'users', so jkirk and ksingh can access all files in the directory. Then, jkirk creates a directory to share with wriker. He does the same, except adds wriker to the access list. Same thing, but ksingh can't access any of the files in it because the directory is 700 and so he can't list the files and, even if he could, he can't actually traverse the directory to access the files. Similarly, wriker can't access the directory shared by ksingh. And, of course, jkirk has been granted no additional permissions. Still, wriker or ksingh could do the same to give jkirk or each other shared directories to access. It's a simple create directory, right click, add access, and there's no implications of other access by other people because of other stuff you did with other directories at other times. Also, the system administrator isn't involved. That's called keeping it simple. What's simple with the current design is nobody has to develop a user interface for managing POSIX ACLs--which would of course involve work, and open source developers are a limited resource because they only work on things they actually care about. What's simple about the proposed design is the end user doesn't have to change what group people are in or do complicated association graphs and jump through hoops to get the simplest sharing between two users to not open up other files they don't intend to share. Also important is, with the current design, if you share with more than one or two other users or you have overlapping access you WILL wind up giving excessive access to someone. For example, one user creates a shared directory with two users, and another shared directory with only one of those two users. You can't
Re: Default group
On Wed, Oct 17, 2012 at 3:52 PM, John Moser john.r.mo...@gmail.com wrote: First: that's why we need an interface that handles POSIX ACLs properly, long-overdue. It actually occurs to me that this is probably not just technically important, but important for planning purposes. That is, we can sit here arguing all day about theoretical use cases, but everybody is going to have differing opinions that lean in odd directions until certain things are fixed. Or in short, as long as POSIX ACLs require a scout badge in command line comfort, discussing how to leverage POSIX ACLs is pointless because people don't want to think two steps out. Let's see if we can get anything agreeable on that. It'll probably look strikingly like Windows' Security tab, except without supplying Allow/Deny, fine grained special permissions (which don't exist), or having all the Windows main permissions. So, it'll look like the only thing that makes sense in general, and specifically for Unix. That is, a few rows of controls for Owner, Group, and then a list box of permissions with one row with three checkboxes per row for each user (Owner, Group, Everyone, individual users/groups). Can we get that? -- 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
Re: Default group
It's called eiciel -- Matt Wheeler m...@funkyhat.org On 17 Oct 2012 21:15, John Moser john.r.mo...@gmail.com wrote: On Wed, Oct 17, 2012 at 3:52 PM, John Moser john.r.mo...@gmail.com wrote: First: that's why we need an interface that handles POSIX ACLs properly, long-overdue. It actually occurs to me that this is probably not just technically important, but important for planning purposes. That is, we can sit here arguing all day about theoretical use cases, but everybody is going to have differing opinions that lean in odd directions until certain things are fixed. Or in short, as long as POSIX ACLs require a scout badge in command line comfort, discussing how to leverage POSIX ACLs is pointless because people don't want to think two steps out. Let's see if we can get anything agreeable on that. It'll probably look strikingly like Windows' Security tab, except without supplying Allow/Deny, fine grained special permissions (which don't exist), or having all the Windows main permissions. So, it'll look like the only thing that makes sense in general, and specifically for Unix. That is, a few rows of controls for Owner, Group, and then a list box of permissions with one row with three checkboxes per row for each user (Owner, Group, Everyone, individual users/groups). Can we get that? -- 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 -- 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
Re: Default group
On 12-10-17 03:52 PM, John Moser wrote: Let's first assume we have three users: jkirk ksingh wriker Now, let's say any of these wants to give any of the others access to his files in general (i.e. his $HOME). Let's for our example say jkirk wants wriker to have access. First, he must find the sysadmin. The sysadmin must then put wriker in group jkirk. Also, ~jkirk must be group-readable, as must any files. In a default Ubuntu installation, jkirk's files are already accessible to other users. To do this without a sysadmin, the user must be sysadmin. Either none or one of these users can do it all; or all of them can and then we're not dealing with any kind of document security. With POSIX ACL instead AND AN INTERFACE FOR IT, jkirk simply right-clicks on his Home directory in Nautilus (Konqueror Thunar etc), hits Permissions, Add, puts in 'wriker' with 'read, access files inside directory'. Since his files are all read-write by group (umask=002) instead of just readable (umask=022), this makes all his files writable by wriker, of course. That's not the point here, HOWEVER it is a concern. Notice this is simple, and the user can do it themselves. A user can't change permissions on his $HOME by himself. Only a sysadmin can. Someone raised shared directories and SGID. When we get to SGID we've stepped slightly outside simple, but I'll allow it. Let's say now jkirk wants to share specific files with wriker, and specific other files with ksingh. Let's tackle ksingh first. jkirk could put a directory in a shared location, with SGID, accessible by jkirk, and have the sysadmin give ksingh the jkirk group. This would, of course, also allow ksingh into anything else accessible by jkirk's group--so if his home directory is open, or if he has a file shared with wriker by putting wriker in the jkirk group, those files are also accessible by ksingh as a matter of course. Repeat: those OTHER files are also accessible by ksingh as a matter of course. Instead, ksingh could have jkirk put in the ksingh group; this creates the same problem for ksingh. Next of course jkirk tries to create a shared directory to share some files with wriker, but of course that makes things complex. Maybe wriker does it, but then he shares with ksingh, which means wriker has the same problem of jkirk getting files he wants to only share with ksingh, or jkirk must accept the problem of sharing files with ksingh when he only wants those files to go to wriker (and with wriker when he wants those files only to go to ksingh). Then, everybody gives up and just uses e-mail to send files back and forth. Instead, jkirk creates a directory to share with ksingh. The directory is mode 700, owned by jkirk, and in the group 'users', and with the SGID bit set (so not mode 700, more mode 02700? I forget what's SUID, SGID, and sticky, ok?). He right clicks on it, hits Properties, Permissions, adds ksingh with rwx (remember X on directories is access files inside). When jkirk or ksingh creates files inside, they are read/write by group and automatically in the group 'users', so jkirk and ksingh can access all files in the directory. This only works if the user default umask is 002, which wouldn't be the case if you're not using User Private Groups. Marc. -- 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
Re: Default group
Doesn't look integrated into the default UI. Workable, but not quite intuitive. Things I'd prefer: - Shows the user and group ownership, instead of piling them is as just part of the ACL. Remember these have special meanings for SUID/SGID. - First three ACL entries are always Owner, Group, and Other. - Integrate into the UI (Konqueror, Gnome) - Apply ACL to Enclosed Files button to apply the ACL all the way down. - Possibly Apply Permissions to Enclosed Files button for only UNIX permissions i.e. something more obvious and intuitive. On 10/17/2012 05:12 PM, Matt Wheeler wrote: It's called eiciel -- Matt Wheeler m...@funkyhat.org mailto:m...@funkyhat.org On 17 Oct 2012 21:15, John Moser john.r.mo...@gmail.com mailto:john.r.mo...@gmail.com wrote: On Wed, Oct 17, 2012 at 3:52 PM, John Moser john.r.mo...@gmail.com mailto:john.r.mo...@gmail.com wrote: First: that's why we need an interface that handles POSIX ACLs properly, long-overdue. It actually occurs to me that this is probably not just technically important, but important for planning purposes. That is, we can sit here arguing all day about theoretical use cases, but everybody is going to have differing opinions that lean in odd directions until certain things are fixed. Or in short, as long as POSIX ACLs require a scout badge in command line comfort, discussing how to leverage POSIX ACLs is pointless because people don't want to think two steps out. Let's see if we can get anything agreeable on that. It'll probably look strikingly like Windows' Security tab, except without supplying Allow/Deny, fine grained special permissions (which don't exist), or having all the Windows main permissions. So, it'll look like the only thing that makes sense in general, and specifically for Unix. That is, a few rows of controls for Owner, Group, and then a list box of permissions with one row with three checkboxes per row for each user (Owner, Group, Everyone, individual users/groups). Can we get that? -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com mailto:Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss -- 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
Re: Default group
On 10/17/2012 05:34 PM, Marc Deslauriers wrote: On 12-10-17 03:52 PM, John Moser wrote: First, he must find the sysadmin. The sysadmin must then put wriker in group jkirk. Also, ~jkirk must be group-readable, as must any files. In a default Ubuntu installation, jkirk's files are already accessible to other users. Yeah I just looked and saw that, my whole $HOME is world-readable. This displeases me. I'd prefer default $HOME chmod 700. A user can't change permissions on his $HOME by himself. Only a sysadmin can. $ ls -ld ~ drwxr--r-x 100 bluefox bluefox 4096 Oct 14 11:47 /home/bluefox $ chmod go-rx ~ $ ls -ld ~ drwx-- 100 bluefox bluefox 4096 Oct 14 11:47 /home/bluefox $ setfacl -m u:root:r ~ $ getfacl ~ # file: home/bluefox # owner: bluefox # group: bluefox user::rwx user:root:r-- group::--- mask::r-- other::--- Try again. This only works if the user default umask is 002, which wouldn't be the case if you're not using User Private Groups. Well, it's the case now; and if we leave it the case and make ACL handling more intuitive, then it'll all work. Changing $HOME to 700 instead of 755 would adequately protect the user's private files in $HOME even with a umask of 002, since you simply can't look into $HOME to read/modify those files anyway. The only other thing needed would then be a Shared Documents alike (borrowing from Windows again--it's a pile of crap but that doesn't mean everything associated is terrible by default) supplying a place for folks to put shared files or such secured shared folders, made sticky of course. Marc. -- 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
Re: Default group
On 12-10-17 05:45 PM, John Moser wrote: On 10/17/2012 05:34 PM, Marc Deslauriers wrote: On 12-10-17 03:52 PM, John Moser wrote: First, he must find the sysadmin. The sysadmin must then put wriker in group jkirk. Also, ~jkirk must be group-readable, as must any files. In a default Ubuntu installation, jkirk's files are already accessible to other users. Yeah I just looked and saw that, my whole $HOME is world-readable. This displeases me. I'd prefer default $HOME chmod 700. As I said, we wanted people to be able to share files by default without having to understand granting permissions. This has already been discussed to death, although it's been a while. A user can't change permissions on his $HOME by himself. Only a sysadmin can. $ ls -ld ~ drwxr--r-x 100 bluefox bluefox 4096 Oct 14 11:47 /home/bluefox $ chmod go-rx ~ $ ls -ld ~ drwx-- 100 bluefox bluefox 4096 Oct 14 11:47 /home/bluefox $ setfacl -m u:root:r ~ $ getfacl ~ # file: home/bluefox # owner: bluefox # group: bluefox user::rwx user:root:r-- group::--- mask::r-- other::--- Try again. Of course, you're absolutely right. I'm not sure what I was thinking there for a sec. :P This only works if the user default umask is 002, which wouldn't be the case if you're not using User Private Groups. Well, it's the case now; and if we leave it the case and make ACL handling more intuitive, then it'll all work. Changing $HOME to 700 instead of 755 would adequately protect the user's private files in $HOME even with a umask of 002, since you simply can't look into $HOME to read/modify those files anyway. I'm not sure this proposal would be simple enough to be understood by most non-technical users. Also, last time we looked at using extended attributes, there were issues with proper support in common tools, backup software, certain filesystems, etc. This would need to be looked at again to see if extended attributes can be used now. It's certainly worth investigating it again. The only other thing needed would then be a Shared Documents alike (borrowing from Windows again--it's a pile of crap but that doesn't mean everything associated is terrible by default) supplying a place for folks to put shared files or such secured shared folders, made sticky of course. Well, right now we're defaulting to sharing everything except private information in private directories. Your proposal is basically to share nothing, and create exceptions. If this is to be discussed again, we probably need to figure out if our users are able to understand file permissions well enough to be able to share documents. Of course, this is all moot without home directory encryption, and when you turn that on, there's basically no sharing at all. Marc. -- 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
Re: Default group
On 10/17/2012 06:43 PM, Marc Deslauriers wrote: On 12-10-17 05:45 PM, John Moser wrote: On 10/17/2012 05:34 PM, Marc Deslauriers wrote: On 12-10-17 03:52 PM, John Moser wrote: First, he must find the sysadmin. The sysadmin must then put wriker in group jkirk. Also, ~jkirk must be group-readable, as must any files. In a default Ubuntu installation, jkirk's files are already accessible to other users. Yeah I just looked and saw that, my whole $HOME is world-readable. This displeases me. I'd prefer default $HOME chmod 700. As I said, we wanted people to be able to share files by default without having to understand granting permissions. This has already been discussed to death, although it's been a while. It's good to revisit things. I'm bringing up what's turning into an evolving alternate proposal, at this point I've gotten as far out as suggesting UI changes and a sticky bit (= /tmp) directory acting as a Shared Documents between users, which I'm guessing didn't come up last round. Sometimes the rules change. Of course, you're absolutely right. I'm not sure what I was thinking there for a sec. :P Wrong facility probably. Changing permission != changing group, which is what this discussion started on. I'm not sure this proposal would be simple enough to be understood by most non-technical users. Also, last time we looked at using extended attributes, there were issues with proper support in common tools, backup software, certain filesystems, etc. This would need to be looked at again to see if extended attributes can be used now. It's certainly worth investigating it again. I may as well continue beating the Look at Windows horse, it's done this right for ages anyway. You should consider your user base though: they've already installed Ubuntu. Most of them. Some probably got a tablet or such that came with it, but single-user systems likely do not care. We're talking about shared multi-user systems where everyone isn't admin, which is kind of a narrow case. That's less most users don't need to know how and more most users won't be faced by a sudden, surprising, confusing change (like moving from Gnome2 to Ubiquity or Gnome3 by default?). In other words, I suspect most users aren't particularly attached to the sharing my files with everyone else case. Finally on that discussion, the current case is--as discussed--a default Share with everyone, and the user has to take an unknown technical step to stop that. That means it's hard (for some value of hard) for some 14 year old girl to stop her little brother from reading her diary. Fortunately actual e-mails are stored in a directory Thunderbird by default forces to 700, although any attachments you save you'll need to purposely revoke permission on. Mostly to the point, documents, saved attachments, saved files off Web sites, PDF collections of Victorian era pornography downloaded from torrents, all by default available without jumping through technical hoops. Don't know about common tools, backup software. I'm well aware it's not straight out-of-box supported by Thunar, Nautilus, and Konqueror--it works, but their file properties dialogs don't let you manage those permissions. Again, Windows does this right. As for filesystems, POSIX ACLs tend to cause issues with read latency for inodes not in disk cache. XFS with 256 byte inodes takes something like 9uS to read a non-ACL inode, 7000uS for an ACL inode; XFS with 512 byte inodes takes 9us either way; and other file systems tend to behave like XFS with 256 byte inodes (9uS-15uS without POSIX ACL, 1000-1500mS with it). This is because another seek-and-read must be done. Not a problem on SSD. not a problem on a warm system, minor performance issue at first boot. This isn't something that's going to slow the system to a crawl: these ACLs are only going to be set on user-owned files, and even then the proposed semantics favor setting them on a directory here and there and so you lose a millisecond or three once in a great while. Do note that performance issues are circa 2003: http://users.suse.com/~agruen/acl/linux-acls/online/ The only other thing needed would then be a Shared Documents alike (borrowing from Windows again--it's a pile of crap but that doesn't mean everything associated is terrible by default) supplying a place for folks to put shared files or such secured shared folders, made sticky of course. Well, right now we're defaulting to sharing everything except private information in private directories. Your proposal is basically to share nothing, and create exceptions. If this is to be discussed again, we probably need to figure out if our users are able to understand file permissions well enough to be able to share documents. I recall Windows XP notifying users that it was in fact going to privatize directories after upgrade, or some such. Such flip-flops have been done. Users
