maindavfs2 - Support: sr #108432, File creation and group ownership

 
 

sr #108432: File creation and group ownership

Submitter:  Miguel Coca <mcoca>
Submitted:  Tue 05 Nov 2013 10:38:16 AM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  _71007
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 14 Apr 2014 07:40:21 AM UTC, comment #7: 

Thanks for accepting the patch.

Your changes make sense, and I believe they won't conflict with our (rather particular) usage.

Miguel Coca <mcoca>
Sun 13 Apr 2014 10:22:33 AM UTC, comment #6: 

I applied the patch to the CVS sources branch MAIN and branch rel-1-4-6.

Hello Miguel,

I applied some changes to your patch:

  • when the directory has group root an unprivileged user would be able to create files with group root. I am not sure whether this is a security risk, but to avoid any risk davfs2 will ignore option grpid in this case.


  • most file attributes are not stored on the server e.g. the group. So after a remount the group would be set to the default. To avoid this option grpid is also applied when a node is created for files that are already on the server.


  • when an unprivileged user mounts, davfs2 checks fstab to prevent users from setting options different from fstab. I added a check for option grpid.


Cheers
Werner

- <_71007>
Sat 09 Nov 2013 08:42:04 PM UTC, comment #5: 

Thanks for the patch. I did not look at the details but I like the idea of the grpid option and will probably include your path. But it will take time.

The reason for not allowing the s-bits: files from a remote server are easier to manipulate than local ones. So for security reasons it seems a good idea not to allow setuid files. I'm not that sure with setgid and as I am not sure I decided to be (overly) restrictive.

Cheers
Werner



- <_71007>
Fri 08 Nov 2013 12:29:24 PM UTC, comment #4: 

I attach my implementation of the grpid flag, in case you find it of use.

Thanks,

(file #29571)

Miguel Coca <mcoca>
Wed 06 Nov 2013 03:59:29 PM UTC, comment #3: 

Hello again,

I have successfully modified 1.4.6 to re-enable the suid option at mount time, and give the setgid bit on directories the same semantics as on default ext filesystems.

In the process, I have concluded it makes more sense to implement this functionality differently, as in the "grpid" option of ext2/3 filesystems: if activated, new files will inherit the group ownership of their parent directory, so I will try and code that next.

Would you be open to including either of these features in davfs?

Thanks,

Miguel Coca <mcoca>
Tue 05 Nov 2013 09:13:45 PM UTC, comment #2: 

Thank you for the reply!

I understand the logic behind the current behaviour, but it is a pain for our users. I was looking for some way to bypass it. Similar to how a normal unix filesystem treats setgid on directories, setting the group of new files to that of the parent directory.

Is there any particular reason you "silently ignore" (as per the man page) the s-bits for dir_mode? That would fix my problem perfectly. If there's no special reason why it shouldn't be done, I would like to try to patch them in.

Thank you again,

Miguel Coca <mcoca>
Tue 05 Nov 2013 08:29:11 PM UTC, comment #1: 

This is a misunderstanding about the meaning of the options uid and gid.

Files in the file system will belong to this user and this group as long as there is no other information about owner and group. Standard WebDAV does not know about owner and group af a file. So if a file on the server is listed in your file system for the first time it will have this uid and gid.

When a user creates a file davfs2 gets from the file system interface (via the kernel) information about the owner and the group of the file and sets owner and group accordingly. Simply: normal Unix file system rules apply: a newly created file is owned by the creator and belongs to the primary group of the owner.

This information can not be stored on the server (it could, but this would require davfs2 specific changes that are not recognised by other WebDAV clients). If you access the file from another client it will have the default uid and gid.

Werner

- <_71007>
Tue 05 Nov 2013 10:38:16 AM UTC, original submission:  

Hello,

I have a davfs installation where several users in the same unix group access the same davfs mount point.

The folder is mounted under /data/groupX/, and has gid set to groupX (and dir/file modes 770/660). The problem is that, when an user creates a file in this folder, it belongs to the user's primary group, and not groupX by default.

Unless the user remembers to chown the file, it is inaccessible to other members of the group on the same machine. Yet, the same users accessing the file from another machine can read it just fine.

Is there any way to change this behaviour?

Miguel Coca <mcoca>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #29571:  davfs2_grpid.patch added by mcoca (5KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by _71007 (Posted a comment)
  • -email is unavailable- added by mcoca (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-04-22 _71007 Open/ClosedOpen Closed
    2014-04-13 _71007 StatusIn Progress Done
    2013-11-08 mcoca Attached File- Added davfs2_grpid.patch, #29571
    2013-11-05 _71007 StatusNone In Progress
        Assigned toNone _71007

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code