Files moved to a shared project folder retain original Group

[John Hupp]

On 1/22/2013 9:19 PM, Ioannis Vranos wrote:
> On Wed, Jan 23, 2013 at 1:45 AM, John Hupp <lubuntu at prpcompany.com> wrote:
>> I got started on this general topic in the thread "Make new user sub-folders
>> inherit parent permissions," but wanted to start a new thread to reflect the
>> current state of development.
>>
>> The goal: A shared folder tree that a group of users can freely edit
>> (suitable for a project team, for instance).
>>
>> After multiple exchanges here and a lot of reading, I concluded that the
>> usual approach is to set the folder's SetGID bit after changing the folder's
>> Group from the default owner-named group to a group that contains all the
>> required users.
>>
>> So in my little scenario with just user1 and user2:
>> - Add user1 and user2 to the existing "users" group
>> - As root, create /home/Shared
>> - Edit /home/Shared ownership and permissions:
>>          Owner: root --> user1 (maybe I didn't have to, but it seemed odd
>> retaining root as the owner)
>>          Group: root --> users
>>          Change Content: Only owner --> Only owner and group
>> - chmod g+s /home/Shared (this takes care of the Set-Group-ID bit)
>> - Create symlinks to /home/Shared in the user1 and user2 home directories
>>
>> Then I confirmed what some had already noted as a problem with this
>> arrangement: It works fine with sub-folders and files created afresh in
>> Shared, but folders/files copied or moved in from elsewhere retain their
>> original group, and are not editable by all users in "users" until the group
>> property is manually reassigned to "users."
>>
>> The only workaround (to manual group reassignment) I have uncovered so far
>> is to create a cron job that periodically fixes such files/folders.
> Setting a cron job to apply ownership to /home/shared, every minute or
> so, looks interesting.
>
> The only thing about standard filesystem ownership, unmentioned in
> this thread is the sticky bit (not useful in your case).
>
> For more complex user access control, Access Control List (ACL) is
> used, but I do not know much about it.
>
>
>> Is there anything better?  A modest little daemon that can be set to monitor
>> the folder tree?
> May be there is some such service indeed.
>
> Just googled, and found this: http://goo.gl/QvqPV
>
I had a look at ACL usage today in the midst of this, and found that one 
often-cited and well-written thread applies it to solve half of a 
folder-sharing problem.  (See 
http://brunogirin.blogspot.com/2010/03/shared-folders-in-ubuntu-with-setgid.html.) 
Which is to say, SetGID takes care of the problem of new 
sub-folders/files being assigned the primary group of the creator 
(rather than the special group with the project team users).  But in 
some systems on which the default user umask is 022, there remains a 
problem in which write permission of new folders/files is granted only 
to the owner, not to the group.  One application of ACL is to create a 
default ACL permissions set that overrides that and creates write 
permission for the owner *and* group.

But in Lubuntu and probably other ?buntu's, the default user umask is 
002, which already grants write permission to the owner and group, so 
the ACL setup is not needed for this purpose.

----------------------

Your Google search results are interesting.  At the briefest of first 
looks, it seems like inotify may merit further study.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/lubuntu-users/attachments/20130122/5543ece8/attachment.html>