chown doesn't deny unprivileged use

[GoogleCodeExporter]

A non-privileged user can chown a file owned by another user. Most serious is 
that a user can change file ownership to and from root.

What steps will reproduce the problem?

% whoami
mooredan

% ls -l fstab
-rw-r--r-- 1 root root 1719 Jun 30 22:54 fstab

% chown ftp:ftp fstab

% ls -l fstab
-rw-r--r-- 1 ftp ftp 1719 Jun 30 22:54 fstab

% chown mooredan:mooredan fstab

% ls -l fstab
-rw-r--r-- 1 mooredan mooredan 1719 Jun 30 22:54 fstab

> chown root:root fstab

> ls -l fstab
-rw-r--r-- 1 root root 1719 Jun 30 22:54 fstab

What is the expected output? What do you see instead?

> ls -l fstab
-rw-r--r-- 1 root root 1688 Mar  7 20:18 fstab

% chown mooredan:mooredan fstab
chown: changing ownership of `fstab': Operation not permitted

What version of the product are you using? On what operating system?
r191   Debian Sid

Please provide any additional information below.

Original issue reported on code.google.com by moore...@gmail.com on 1 Jul 2010 at 5:14

[GoogleCodeExporter]

This is tricky because the uid/gid of the user calling `chown` are masked by 
the s3fs process owner. Do we just assume that's okay? What if s3fs is running 
as root with 'allow_other'?

Original comment by ben.lema...@gmail.com on 10 Mar 2011 at 9:51

[GoogleCodeExporter]

I think that the "correct" operation should be like that of an nfs mount.  
Instead of using the fuse option "allow_other", couldn't the normal mount 
options of ro, rw, uid=, gid=, umask= be used?

It may take some experimentation to figure it out. ...or maybe allow_other is 
needed as well?

...or maybe it is up to us to detect the unprivileged operation and return the 
correct error code from s3fs?

Original comment by dmoore4...@gmail.com on 11 Mar 2011 at 2:47

[GoogleCodeExporter]

Hi

This issue is old s3fs version.
Latest version(now v1.69) fixes this issue, s3fs handles file permission on 
s3fs mount.

Please use latest version and if you have a issue, please post new issue.

Thanks a lot.

Original comment by ggta...@gmail.com on 29 May 2013 at 8:11

• Changed state: Fixed