Re: bug#70214: 'install' fails to copy regular file to autofs/cifs, due to ACL or xattr handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 15/04/2024 15:37, Andreas Grünbacher wrote:
Hello,

Am So., 14. Apr. 2024 um 00:43 Uhr schrieb Pádraig Brady <P@xxxxxxxxxxxxxx>:
On 13/04/2024 20:29, Bruno Haible wrote:
Hi Pádraig,

I wrote:
5) The same thing with 'cp -a' succeeds:

$ build-sparc64/src/cp -a /var/tmp/foo3941 $HOME/foo3941; echo $?
0
$ build-sparc64-no-acl/src/cp -a /var/tmp/foo3941 $HOME/foo3941; echo $?
0

You wrote:
The psuedo code that install(1) uses is:

copy_reg()
     if (x->set_mode) /* install */
       set_acl(dest, x->mode /* 600 */)
         ctx->acl = acl_from_mode ( /* 600 */)
         acl_set_fd (ctx->acl) /* fails EACCES */
         if (! acls_set)
            must_chmod = true;
         if (must_chmod)
           saved_errno = EACCES;
           chmod (ctx->mode /* 600 */)
           if (save_errno)
             return -1;

And, for comparison, what is the pseudo-code that 'cp -a' uses?
I would guess that there must be a relevant difference between both.

The cp pseudo code is:

copy_reg()
    if (preserve_xattr)
      copy_attr()
        ret = attr_copy_fd()
        if (ret == -1 && require_preserve_xattr /*false*/)
          return failure;
    if (preserve_mode)
      copy_acl()
        qcopy_acl()
          #if USE_XATTR /* true */
            fchmod() /* chmod before setting ACLs as doing after may reset */
            return attr_copy_fd() /* successful if no ACLs in source */
          #endif

If however you add ACLs in the source, you induce a similar failure:

$ setfacl -m u:nobody:r /var/tmp/foo3942
$ src/cp -a /var/tmp/foo3942 foo3942; echo $?
src/cp: preserving permissions for ‘foo3942’: Permission denied
1

The corresponding strace is:

fchmod(4, 0100640)                      = 0
flistxattr(3, NULL, 0)                  = 24
flistxattr(3, "system.posix_acl_access\0", 24) = 24
fgetxattr(3, "system.posix_acl_access", NULL, 0) = 44
fgetxattr(3, "system.posix_acl_access", "\2\0...\4", 44) = 44
fsetxattr(4, "system.posix_acl_access", "\2\0...\4", 44, 0) = -1 EACCES (Permission denied)

Why does CIFS think EACCES is an appropriate error to return here? The
fchmod() succeeds, so changing the file permissions via fsetxattr()
should really succeed as well.

Right, it seems like a CIFS bug (already CC'd)
Even if it returned ENOTSUP (like getxattr(...posix...) does) it would be ok as we handle that.
It would be good to avoid it though.

You confirmed privately to me that the set_acl() is to clear any default ACLs
that may have been added to the newly created file, so the posted solution in
https://bugs.gnu.org/70214#11 that only does the set_acl() iff file_has_acl()
should avoid the CIFS issue.  It would be a bit less efficient if there were
ACLs, but a bit more efficient in the common case where there weren't ACLs.

cheers,
Pádraig




[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux