bash test -w (writeable) always SUCCEED on EncFS + linux-2.6.24.X ?

[bo]

While putting a sourcecode Archiv tree on an encfs - Filesystem I recognised,
that my shell scripts which check if a file is writeable FAILED, because
if [ -w $file ] then ... always results true (file shows on ls only readonly !)
Environment:
OpenSuSE 10.3, linux-2.6.24.2, FUSE 2.7.2 without kernel module, encfs-1.4.1.1

If I untar the same src - Code Archiv on an normal Reiserfs - Filesystem,
if [ -w $file ] behaves normal. I "feel" it depends on an linux Kernel
update, because on a latest linux-2.6.23.X I reached the same.
If I edit this file via vi - Editor, it shows the readonly file correct as readonly !
=> There must be an combination of Kernel, BASH, encfs which results in
this ERROR. My encfs - Filesystem ist mounted -public !

[Valient Gough (vgough)]

I'm not able to reproduce with Encfs 1.4.1.1, Fuse 2.7.0, linux 2.6.22:

$ cd crypt
$ touch foo
$ test -w foo && echo rw
rw
$ chmod -w foo
$ test -w foo && echo rw
$

[bo (bernd-oelker)]

Hallo,

Thank you for your quick response. Before I have also no problem with
Linux-2.6.XX (XX < 24) and encfs-1.3.2, but now it comes up ...
Sorry for the wrong Header it is linux-2.6.24.2 and I remember to
"see" this also on for example Linux 2.6.23.14 ...
Perhaps it is related to some Kernel change(s) like the following

From Changelog vanilla Kernel

commit 5b59039024e391cd5014db41ca8a89f0e2a0dabe
Author: Greg Kroah-Hartman <email address hidden>
Date: Mon Jan 14 12:49:56 2008 -0800

    Linux 2.6.23.14

commit 3093d39c9361dae001efaea9279b0b23e38f049c
Author: Linus Torvalds <email address hidden>
Date: Sat Jan 12 14:06:34 2008 -0800

    Use access mode instead of open flags to determine needed permissions (CVE-2008-0001)

    patch 974a9f0b47da74e28f68b9c8645c3786aa5ace1a in mainline

    Way back when (in commit 834f2a4a1554dc5b2598038b3fe8703defcbe467, aka
    "VFS: Allow the filesystem to return a full file pointer on open intent"
    to be exact), Trond changed the open logic to keep track of the original
    flags to a file open, in order to pass down the the intent of a dentry
    lookup to the low-level filesystem.

    However, when doing that reorganization, it changed the meaning of
    namei_flags, and thus inadvertently changed the test of access mode for
    directories (and RO filesystem) to use the wrong flag. So fix those
    test back to use access mode ("acc_mode") rather than the open flag
    ("flag").

    Issue noticed by Bill Roman at Datalight.

    Reported-and-tested-by: Bill Roman <email address hidden>
    Acked-by: Trond Myklebust <email address hidden>
    Acked-by: Al Viro <email address hidden>
    Cc: Christoph Hellwig <email address hidden>
    Cc: Andrew Morton <email address hidden>
    Signed-off-by: Linus Torvalds <email address hidden>
    Signed-off-by: Greg Kroah-Hartman <email address hidden>

Or for Kernel 2.6.24

commit 974a9f0b47da74e28f68b9c8645c3786aa5ace1a
Author: Linus Torvalds <email address hidden>
Date: Sat Jan 12 14:06:34 2008 -0800

    Use access mode instead of open flags to determine needed permissions

    Way back when (in commit 834f2a4a1554dc5b2598038b3fe8703defcbe467, aka
    "VFS: Allow the filesystem to return a full file pointer on open intent"
    to be exact), Trond changed the open logic to keep track of the original
    flags to a file open, in order to pass down the the intent of a dentry
    lookup to the low-level filesystem.

    However, when doing that reorganization, it changed the meaning of
    namei_flags, and thus inadvertently changed the test of access mode for
    directories (and RO filesystem) to use the wrong flag. So fix those
    test back to use access mode ("acc_mode") rather than the open flag
    ("flag").

    Issue noticed by Bill Roman at Datalight.

    Reported-and-tested-by: Bill Roman <email address hidden>
    Acked-by: Trond Myklebust <email address hidden>
    Acked-by: Al Viro <email address hidden>
    Cc: Christoph Hellwig <email address hidden>
    Cc: Andrew Morton <email address hidden>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundati...

[bo (bernd-oelker)]

Hallo,

If I do your small example like

$ cd crypt
$ touch foo
$ test -w foo && echo rw
rw
$ chmod -w foo
$ test -w foo && echo rw
$

I got 2 times rw !!
If I do the same on /tmp (ReiserFS) it work like your example
(mean only one time rw)

[Valient Gough (vgough)]

Ok.. I've send mail to the FUSE development list, because this is most likely either an issue in your particular kernel, or the FUSE kernel layer.

[Valient Gough (vgough)]

The FUSE author (Miklos) has found the problem in the FUSE kernel module. He has suggested the following fix:

Index: linux-2.6.24/fs/fuse/dir.c
===================================================================
--- linux-2.6.24.orig/fs/fuse/dir.c 2008-02-10 18:40:19.000000000 +0100
+++ linux-2.6.24/fs/fuse/dir.c 2008-02-15 10:20:27.000000000 +0100
@@ -905,7 +905,7 @@ static int fuse_permission(struct inode
       }

       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

Thanks for the report!

[Valient Gough (vgough)]

I'm closing this as Invalid because it has been confirmed as a FUSE problem and not Encfs.. 'Invalid' doesn't mean this was not helpful, but no changes are necessary in encfs, and there is no FUSE project listed in the bug tracker, so I can't transfer this ticket.

thanks,
Valient

[Chris Coulson (chrisccoulson)]

Valient - This is a bug with the FUSE kernel module which is shipped with the kernel, so it should be assigned to the kernel.

It also still exists, so I'm confirming. You might find this useful: http://article.gmane.org/gmane.comp.file-systems.fuse.devel/5789

I discovered this bug because I am testing bindfs. I've created the following bindfs mount in my fstab:

"bindfs#/home/.shared /home/shared fuse owner=root,group=root,mirror=@shared-rw,perms=000:u+rwX:g+rX:o+rX 0 0"

Basically, /home/shared should only be writable by anybody belonging to the group 'shared-rw'. /home/shared should be readable by everybody. However, I find that any user can write to /home/shared, regardless of whether they belong to the group 'shared-rw'.

[bo (bernd-oelker)]

Hallo,

The reason for this Fuse Bug was a simple Typo in the FuSE kernel Module...,
Becaus a local variable shdows a global one ....

Valient Gough [<email address hidden>] wrote at Sa 16.02.2008:

>The FUSE author (Miklos) has found the problem in the FUSE kernel module. He has suggested the following fix:

>Index: linux-2.6.24/fs/fuse/dir.c
>===================================================================
>--- linux-2.6.24.orig/fs/fuse/dir.c 2008-02-10 18:40:19.000000000 +0100
>+++ linux-2.6.24/fs/fuse/dir.c 2008-02-15 10:20:27.000000000 +0100
>@@ -905,7 +905,7 @@ static int fuse_permission(struct inode
> }

> 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
>
>
>Thanks for the report!

So, this problem has been detected quick, and hopefully all further FuSE Releases are
Error free concerning this bug

________________________________

Bernd Oelker
HSP GmbH
48149 Münster
Johann-Krane-Weg 21
Germany
Tel: [phone]
Fax: [phone]
Mobil: [phone]
Web: www.hspg.de
Web: www.hsp-translog.de
E-Mail: <email address hidden>

Sitz: Münster
Amtsgericht Münster HRB 2485
Geschäftsführung: Dipl.-Ing Klaus Hiesgen, Dipl.-Phys. Bernd Oelker
________________________________

-----Ursprüngliche Nachricht-----
Von: <email address hidden> [mailto:<email address hidden>] Im Auftrag von Chris Coulson
Gesendet: Montag, 14. Juli 2008 00:42
An: Bernd Oelker [HSP]
Betreff: [Bug 191831] Re: bash test -w (writeable) always SUCCEED on EncFS +linux-2.6.24.X ?

Valient - This is a bug with the FUSE kernel module which is shipped with the kernel, so it should be assigned to the kernel.

It also still exists, so I'm confirming. You might find this useful:
http://article.gmane.org/gmane.comp.file-systems.fuse.devel/5789

I discovered this bug because I am testing bindfs. I've created the following bindfs mount in my fstab:

"bindfs#/home/.shared /home/shared fuse
owner=root,group=root,mirror=@shared-rw,perms=000:u+rwX:g+rX:o+rX
0 0"

Basically, /home/shared should only be writable by anybody belonging to the group 'shared-rw'. /home/shared should be readable by everybody.
However, I find that any user can write to /home/shared, regardless of whether they belong to the group 'shared-rw'.

** Changed in: linux (Ubuntu)
       Status: New => Confirmed

--
bash test -w (writeable) always SUCCEED on EncFS + linux-2.6.24.X ?
https://bugs.launchpad.net/bugs/191831
You received this bug notification because you are a direct subscriber of the bug.

Status in Encrypted Filesystem for Linux: Invalid Status in "linux" source package in Ubuntu: Confirmed

Bug description:
While putting a sourcecode Archiv tree on an encfs - Filesystem I recognised, that my shell scripts which check if a file is writeable FAILED, because if [ -w $file ] then ... always results true (file shows on ls only readonly !)
Environment:
OpenSuSE 10.3, linux-2.6.24.2, FUSE 2.7.2 without kernel module, en...

[Chris Coulson (chrisccoulson)]

Bo - You are correct, but the FUSE kernel module is distributed with the kernel, which is why I have now assigned this bug to the kernel. The bug still exists in Hardy (I checked the code last night).

Unfortunately, this bug report was closed incorrectly. When a bug report is set to 'Invalid', it no longer appears in any searches and is very difficult to find. I found it by chance because it was linked from another website. I would encourage any triager who is unsure whether it is a valid Ubuntu bug to ask somebody on the #ubuntu-bugs IRC channel

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Chris Coulson (chrisccoulson)]

This is fixed in the Intrepid kernel now