Can't combine -o permissions with -o uid=UUU,gid=GGG

Bug #1087915 reported by danmb
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ntfs-3g (Ubuntu)
New
Undecided
Unassigned

Bug Description

At the moment, it seems that mount.ntfs-3g disables -o permissions if -o uid=UUU and/or uid=GGG are also specified. This (combined with Ubuntu's compilation options disallowing user mounts for NTFS-3g) prevents unprivileged users from easily accessing NTFS systems while preserving standard Unix permissions.

root# mount -o uid=500,gid=500,umask=000 /dev/sdb1 /vol/exthd/
root# touch /vol/exthd/x
root# ls -al /vol/exthd/x
-rwxrwxrwx 1 muresan muresan 0 Dec 8 00:29 /vol/exthd/x
root# chmod u-x /vol/exthd/x
root# ls -al /vol/exthd/x
-rwxrwxrwx 1 muresan muresan 0 Dec 8 00:29 /vol/exthd/x

So chmod is ignored and all permissions are fixed to rwx.

With "mount -o permissions", permissions ARE preserved, but all files are owned by root:

root# mount -o permissions /dev/sdb1 /vol/exthd
Using default user mapping
root# touch /vol/exthd/x
root# ls -al /vol/exthd/x
-rw--w--w- 1 root root 0 Dec 8 00:29 /vol/exthd/x
root# chmod u+x /vol/exthd/x
root# ls -al /vol/exthd/x
-rwx-w--w- 1 root root 0 Dec 8 00:29 /vol/exthd/x
root# rm /vol/exthd/x

root# ls -al /bin/bash
-rwxr-xr-x 1 root root 920788 Apr 3 2012 /bin/bash
root# cp -a /bin/bash /vol/exthd/
root# ls -al /vol/exthd/bash
-rwxr-xr-x 1 root root 920788 Apr 3 2012 /vol/exthd/bash
root# umount /vol/exthd

Trying to mount the filesystem as an unprivileged user results in:

Either mount the volume as root, or rebuild NTFS-3G with integrated
FUSE support and make it setuid root. Please see more information at
http://tuxera.com/community/ntfs-3g-faq/#unprivileged

Revision history for this message
danmb (danmbox) wrote :

Note, my shell log shows the behavior with mount -o uid=500,gid=500,umask=000. The same behavior (chmod has no effect) occurs when using mount -o permissions,uid=500,gid=500,umask=000 (as if -o permissions is being silently ignored).

Revision history for this message
Jean-Pierre (jean-pierre-andre) wrote :

"At the moment, it seems that mount.ntfs-3g disables -o permissions if -o uid=UUU and/or uid=GGG are also specified."
Yes, that should be expected. You cannot both define the owner of a file both as the current user and a forced user. See http://www.tuxera.com/community/ntfs-3g-advanced/ownership-and-permissions/#options
"This (combined with Ubuntu's compilation options disallowing user mounts for NTFS-3g) prevents unprivileged users from easily accessing NTFS systems while preserving standard Unix permissions."
This is unrelated. For preserving standard permissions, do not force owner and group which would be a non-standard way of setting permissions.
"With "mount -o permissions", permissions ARE preserved, but all files are owned by root:"
No, should not be. You are probably displaying files not created with option "-o permissions" or files created by root, or files created by Windows. Using "-o permissions" without forcing uid and gid, and not running as root, please post the output of :
id
touch newfile
stat newfile
"root# touch /vol/exthd/x
root# ls -al /vol/exthd/x
-rw--w--w- 1 root root 0 Dec 8 00:29 /vol/exthd/x"
The file x is created by root, it should obviously be owned by root.

Revision history for this message
danmb (danmbox) wrote :

"id; touch newfile; stat newfile"

OK, you are right "-o permissions" alone accurately preserves owners and permissions, which is sort of what I needed. I was confused by some experiments I did with memory sticks accessed from Windows.

"Yes, that should be expected. You cannot both define the owner of a file both as the current user and a forced user. See http://www.tuxera.com/community/ntfs-3g-advanced/ownership-and-permissions/#options"

Ownership and permission are orthogonal settings. You could force ownership while leaving permissions alone.

This would be useful when working with memory sticks that are accessed both in Windows and Linux (because sometimes directories created in Windows will appear owned by root and unwritable).

The permissions/conditions table is actually quite confusing. It's trying to represent a decision tree. I don't have better suggestions though, other than switching the column order, i.e. Condition first, Results second.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.