From: "Pádraig Brady" <P@draigBrady.com>
To: "Andreas Grünbacher" <andreas.gruenbacher@gmail.com>
Cc: Bruno Haible <bruno@clisp.org>,
70214@debbugs.gnu.org,
"linux-cifs@vger.kernel.org" <linux-cifs@vger.kernel.org>
Subject: Re: bug#70214: 'install' fails to copy regular file to autofs/cifs, due to ACL or xattr handling
Date: Mon, 15 Apr 2024 16:28:23 +0100 [thread overview]
Message-ID: <f6561a40-f0db-ea62-6cc6-1147f7fe8bf7@draigBrady.com> (raw)
In-Reply-To: <CAHpGcMJL6rngGunfAfCet9S4eqQ8TE6xgHPwhWx9KA=Ef0aW2w@mail.gmail.com>
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@draigbrady.com>:
>> 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
prev parent reply other threads:[~2024-04-15 15:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6127852.nNyiNAGI2d@nimes>
2024-04-13 16:39 ` bug#70214: 'install' fails to copy regular file to autofs/cifs, due to ACL or xattr handling Pádraig Brady
2024-04-13 19:29 ` Bruno Haible
2024-04-13 22:43 ` Pádraig Brady
2024-04-15 14:37 ` Andreas Grünbacher
2024-04-15 15:28 ` Pádraig Brady [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f6561a40-f0db-ea62-6cc6-1147f7fe8bf7@draigBrady.com \
--to=p@draigbrady.com \
--cc=70214@debbugs.gnu.org \
--cc=andreas.gruenbacher@gmail.com \
--cc=bruno@clisp.org \
--cc=linux-cifs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.