DAC permissions not correctly enforced

I'm guessing this is the same problem as described in bug #198403 (now marked as duplicate of this).

In that case I can confirm this for Hardy Beta, fully updated as of postdate.

(See my bug report for some extra info and a screenshot of the process.)

Ok, I was able to get the desired result (write-protection) by adding the option "ro" in fstab, like so:

ro,defaults,umask=027,gid=46 0 1

strange that this should work and not other things...

especially since they did work before.

Correction: Above fix is does not have desired effect completely:

It disables write access for both group and root, and I'd like to keep root-write...

I have now tried:

In fstab:
switching "ntfs">"ntfs-3g"
adding nouser option
changing gid=46 to gid=0
adding setuid=0 and setgid=0 options.
removing all options except "defaults"

... and everything ends with me still being able to write to the ntfs partition without being root.

This persists on Hardy Final...

Fixed in kernel 2.4.25.

Fixed in kernel 2.6.25.

This meaning that this will be fixed in 8.04.1 probably?

Szabolcs Szakacsits, you mention this is fixed upstream in 2.6.25. Do you have a patch you could point us to or did you just test the upstream 2.6.25 kernel to verify this is no longer an issue. We'd likely want to get this into 8.04.1 but will need to narrow down the fix to apply. I'll do some searching/testing for the exact patch but if you know it off hand that would be great. Thanks.

Search for the FUSE kernel module default_permission fix.

Sorry, the option is default_permissions ('s' in the end).

Thanks for the info. I'm including the upstream git commit id and patch below just for reference. I was able to reproduce the original bug reported here against the 2.6.24-16.30 kernel shipped in Hardy final. I downloaded the 2.6.24-16.30 hardy kernel source and applied the upstream patch. Although the patch does indeed prevent writes when read only permissions are specified, further testing shows it will prohibit reads as well for the user even though read permissions are granted. Also, with the patch applied, writes were never allowed even when write permissions are granted. I've attached the output of a small debug session to show the results. I also tested the upstream 2.6.25 vanilla kernel to see if there were possibly other patches that would fully resolve the issue but I found the same results with the upstream vanilla 2.6.25 kernel as with the Ubuntu 2.6.24 kernel + upstream patch.

Szabolcs, just curious if you have done any further testing with the upstream patch/kernel and if you experience the same results? Thanks.

commit 1a823ac9ff09cbdf39201df37b7ede1f9395de83
Author: Miklos Szeredi <email address hidden>
Date: Sat Feb 23 15:23:27 2008 -0800

    fuse: fix permission checking

    I added a nasty local variable shadowing bug to fuse in 2.6.24, with the
    result, that the 'default_permissions' mount option is basically ignored.

    How did this happen?

     - old err declaration in inner scope
     - new err getting declared in outer scope
     - 'return err' from inner scope getting removed
     - old declaration not being noticed

    -Wshadow would have saved us, but it doesn't seem practical for
    the kernel :(

    More testing would have also saved us :((

    Signed-off-by: Miklos Szeredi <email address hidden>
    Cc: <email address hidden>
    Signed-off-by: Andrew Morton <email address hidden>
    Signed-off-by: Linus Torvalds <email address hidden>

diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
index 7fb514b..c4807b3 100644
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -906,7 +906,7 @@ static int fuse_permission(struct inode *inode, int mask, struct nam
        }

        if (fc->flags & FUSE_DEFAULT_PERMISSIONS) {
- int err = generic_permission(inode, mask, NULL);
+ err = generic_permission(inode, mask, NULL);

                /* If permission is denied, try to refresh file
                   attributes. This is also needed, because the root

I can't see problems in your debug session. Your umask setting causes the permission denied errors, no 'x' on the directories. Try e.g. fmask=337,dmask=227 with the 'ro' mount and it will work fine. Similar logic for 'rw' mounts.

Thanks Szabolcs :) Confirming that using the fmask and dmask parameters as recommended resolve previous issues on patched kernel.

I believe the ubuntu security team is merging patches this week so this should most likely be available in 8.04.1 . Thanks.

dropping the milestone, since this will be handled via security channels.

The current version of the hardy kernel (2.6.24-19.34) still does not enforce the 'default permissions' mount option for fuse mounted filesystems.

I'm using glusterfs which relies upon the 'default permissions' option to do file mode checking, and at the moment any user can write in any directory, remove and overwrite files owned by root and generally wreak havoc.

All that is needed to fix the bug is to remove the word 'int' from fs/fuse/dir.c around line 906 in the kernel, as described in the patch above

Any chance of getting that patch merged into the hardy kernel?

Hi! Yes, that's what the previous "Fix Committed" bug status means. :) A Hardy security update is pending and will be published soon that includes this fix.

Released as part of http://www.ubuntu.com/usn/usn-625-1

TTBOMK, this bug is resolved with the kernel fix and requires no update to ntfs-3g.