Bugzilla Bug 162664

When sys-apps/acl-2.2.39-r1 is compiled with nfs use-flag, there is problems
with acl's on jfs filesystem.
Bug tested on stable (x86) with 2.6.18-gentoo-r6 kernel and on unstable (~x86)
with 2.6.19-gentoo-r4 kernel.
To reproduce this bug:
# dd if=/dev/zero of=img bs=1M count=16
# mkdir mnt
# mkfs.jfs img
# mount -o loop img mnt
# touch mnt/test
# setfacl -m u:<user>:rw mnt/test
(where <user> is some valid user)
The result will be:
"setfacl: mnt/test: No data available"

Here is strace cut of this call:
...
readlink("mnt/test", 0x804d3c0, 4095)   = -1 EINVAL (Invalid argument)
lstat64("mnt/test", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
getxattr("mnt/test", "system.nfs4_acl", 0xbfaa8870, 132) = -1 ENODATA (No data
available)
getxattr("mnt/test", "system.posix_acl_access", 0xbfaa8870, 132) = -1 ENODATA
(No data available)
stat64("mnt/test", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
getxattr("mnt/test", "system.nfs4_acl", 0x0, 0) = -1 ENODATA (No data
available)
setxattr("mnt/test", "system.posix_acl_access",
"\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x02\x00\x06\x00\xe8\x03\x00\x00\x04\x00\x06\x00\xff\xff\xff\xff\x10\x00\x06\x00\xff\xff\xff\xff
\x00\x04\x00\xff\xff\xff\xff", 44, XATTR_REPLACE) = -1 ENODATA (No data
available)
...

Here is ltrace cut of this call:
...
acl_copy_entry(0x8052cf4, 0x8052c80)             = 0
acl_set_tag_type(0x8052cf4, 16)                  = 0
acl_calc_mask(0xbfadc250)                        = 0
acl_check(0x8052c3c, 0xbfadc240)                 = 0
acl_cmp(0x8052bac, 0x8052c3c)                    = 1
acl_set_file("mnt/test", 32768, 0x8052c3c)       = -1
__errno_location()                               = 0xb7fd8690
strerror(61)                                     = "No data available"
...

If sys-apps/acl is compiled with USE="-nfs" than this command is working
properly.
Cut of strace:
...
readlink("mnt/test", 0x804d380, 4095)   = -1 EINVAL (Invalid argument)
lstat64("mnt/test", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
getxattr("mnt/test", "system.posix_acl_access", 0xbfdd7690, 132) = -1 ENODATA
(No data available)
stat64("mnt/test", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
setxattr("mnt/test", "system.posix_acl_access",
"\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x02\x00\x06\x00\x00\x00\x00\x00\x04\x00\x04\x00\xff\xff\xff\xff\x10\x00\x06\x00\xff\xff\xff\xff
\x00\x04\x00\xff\xff\xff\xff", 44, 0) = 0
...

Cut of ltrace:
...
acl_get_entry(0x80518d4, 1, 0xbfd31ee8)          = 1
acl_get_tag_type(0x8051918, 0xbfd31ee4)          = 0
acl_create_entry(0xbfd31f90, 0xbfd31f20)         = 0
acl_copy_entry(0x805198c, 0x8051918)             = 0
acl_set_tag_type(0x805198c, 16)                  = 0
acl_calc_mask(0xbfd31f90)                        = 0
acl_check(0x80518d4, 0xbfd31f80)                 = 0
acl_cmp(0x8051844, 0x80518d4)                    = 1
acl_set_file("mnt/test", 32768, 0x80518d4)       = 0
acl_free(0x80518d4)                              = 0
acl_free(0x8051844)                              = 0
...

There is no such problem with reiserfs, at least. Do not tested other
filesystems.

I got these problems too compiling acl with nfs flag on xfs FS.

Torsten

Created an attachment (id=114019) [edit]
acl_set_file: Don't use XATTR_REPLACE on non-NFS files

This must be applied after acl-2.2.29-CITI_NFS4_ALL-3.dif

I ran into this issue as well, but in cp -Rp.

The difference is in the USE=nfs build, the setxattr call has XATTR_REPLACE;
where in the non-nfs build, it doesn't.  (The NFS patch adds the
XATTR_REPLACE).

The breakage is because setxattr is supposed to fail (errno=ENOATTR) if
XATTR_REPLACE is specified and the file doesn't have the attr to begin with;
which means that acl_set_file() will never be able to add an acl to a file that
lacks an acl to begin with.

I see two ways to fix this:

1) only use XATTR_REPLACE if the target file is NFS

2) test the return value of setxattr(..., XATTR_REPLACE). If -1 and errno ==
ENOATTR, do the setxattr() again without XATTR_REPLACE.

I prefer the first option, because the second adds the extra syscall.  Attached
is the patch I used on my system, which has fixed the problem for me.

*** Bug 167290 has been marked as a duplicate of this bug. ***

*** Bug 177083 has been marked as a duplicate of this bug. ***

Upgrading to sys-libs/glibc-2.5-r2 failed on jfs:
- applied recommended patch for "XATTR_REPLACE on non-NFS files" on
sys-apps/acl
- emerge upgrade of sys-libs/glibc completed without any error!

sys-apps/acl-2.2.39-r1  USE="nfs nls"
sys-fs/jfsutils-1.1.8
x86: 2.6.20-gentoo-r7

Please add patch to acl ebuild!

I'm not sure how that XATTR_REPLACE crept in there in the first place--it looks
like a mistake.  Just remove it and make that argument a zero unconditionally. 
I've pushed out an updated version with that fix to

  git://linux-nfs.org/~bfields/acl.git

Browsable version at

  http://www.linux-nfs.org/cgi-bin/gitweb.cgi?p=bfields-acl.git;a=summary

(PS: Is there a way I could be cc:'d on any bugs related to the citi nfsv4 acl
stuff?)

acl-2.2.45 has latest NFS patch

J. Bruce Fields: there is no way to filter specifically on the nfs patch, but i
can add you as a cc when a new one comes up ...