Add uid, gid and umask support to the filesystem

[GoogleCodeExporter]

This patch adds support for forcing the uid, gid and umask for files and 
folders. The use case would be to emulate something like a USB stick (which 
usually are vfat) through S3. The patch is backend agnostic and should work on 
anyone. I personally tested S3 and local only.

I hope this happen to be useful for somebody else.

Usemode is similar to any other fs supporting this features, it's a set of 
parameters for the mount command.

Example: mount.s3ql -o uid=1000,gid=1000,umask=0755,allow-other local://backend 
mount

Original issue reported on code.google.com by pablo.s...@gmail.com on 3 Nov 2012 at 7:42

Attachments:

• uid_gid_umask.diff

[GoogleCodeExporter]

Thanks for the patch! 

I don't fully understand the usecase yet though. Could you explain in which 
situation I'd use these options? Note that the user calling mount.s3ql already 
has full access to the file system, independent of uid and gid.

Original comment by Nikolaus@rath.org on 3 Nov 2012 at 8:53

• Changed state: NeedsInfo
• Added labels: Type-Wishlist

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Independent of my previous comment, your patch will fail for uid or gid = 0 
(because 0 or 42 == 42).

(previous comment deleted, I misread the patch)

Original comment by Nikolaus@rath.org on 3 Nov 2012 at 9:27

[GoogleCodeExporter]

For some background on a usecase see: http://lwn.net/Articles/497106/, a 
summary of the discussion for the acceptance of a similar patch for the 
ext(2/3/4) fs.

My use case is similar, I have a two applications running over different UIDs 
that were thought to write their output on a vfat partition. Now that I 
switched to s3ql, they couldn't interact with eachother without some code 
modifications that I couldn't make by myself (I don't have sources).

For the uid = 0 thing you're right, I just don't thought it would make much 
sense to use it with uid = 0, but it should either work or warn in some way 
instead of surprise everybody :)

Another point is that it should always mask out the SUID and SGID bits from the 
mask, otherwise it could be a security threat (specially is used with uid = 0 
;) ).

Original comment by pablo.s...@gmail.com on 3 Nov 2012 at 11:30

[GoogleCodeExporter]

Can you tell me what problems you ran into exactly?

The LWN article describes that if you copy data on a USB stick on a computer 
where you have UID 10, you won't be able to access it on another computer where 
you have UID 11.

But that isn't a problem with S3QL, since the user calling mount.s3ql can 
always access all files. I.e., when you mount on the other computer, the files 
will show up as being stored with UID 10 and you will have UID 11, but you'll 
still have full access rights.

Original comment by Nikolaus@rath.org on 3 Nov 2012 at 11:40

[GoogleCodeExporter]

Sure. I have a single mount (mounted as allow-other), that needs to be accessed 
from different applications that are not aware of permissions (they were made 
to work over vfat), when I run them over a s3ql mount they cannot work together 
(ie. files wrote by one app cannot be modified by the other). This is because 
both apps run using different UIDs of course.

My case might be too specific, I'm just committing the patch because I guess 
it's a feature that doesn't interfere with other users/usecases.

I think the summary would be: make a s3ql mount behave like a vfat fs.

Original comment by pablo.s...@gmail.com on 4 Nov 2012 at 12:05

[GoogleCodeExporter]

I'm sorry, but I'm still confused. 

Are the two apps accessing the same mountpoint on the same computer? Then one 
of them will have access, and the other one will not even when using vfat. So I 
believe you are talking about two apps running on different computers?

In that case, why aren't you calling mount.s3ql under the UID that the 
application runs on? 

Original comment by Nikolaus@rath.org on 4 Nov 2012 at 3:57

[GoogleCodeExporter]

Since I don't understand in which situation this feature would be useful, I'll 
close this bug for now. I'm happy to reconsider if someone can help me 
understand the use-case though.

Original comment by Nikolaus@rath.org on 12 Mar 2013 at 3:12

• Changed state: WontFix