Files moved to a shared project folder retain original Group

[John Hupp]

On 1/22/2013 10:53 PM, John Hupp wrote:
> 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.
>

At the cost of a small performance hit, I have set up bindfs for this 
shared folder.  The process was simple:

- Install bindfs
- As root, create /etc/init/mount-bindfs.conf with content as below and 
reboot:
# Remount directories with bindfs
#
# Temporary workaround until BUG 503003 is fixed
#
description "Remount directories with different permissions"
start on stopped mountall
script
     bindfs -o perms=0600,a+X,mirror-only=user1:user2 /home/user1/Shared 
/home/user1/Shared
end script

The first reboot was perceptibly longer than usual, and I wondered if 
this solution was going to cost me a lot on boot-time, but subsequent 
boots were about the same time as before.

The above script causes user1 and user2 to each see themselves as the 
owner of /home/user1/Shared, grants owners read/write permissions on all 
files (but no rights to groups or others), and adds executable 
permission for directories and executables. And this is effective even 
for files/folders which have been moved into the shared folder (which 
was the sticking point for every other proposed solution I found).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/lubuntu-users/attachments/20130124/675684f4/attachment.html>