On Tue, Jul 09, 2024 at 13:20:04 +0200, Thomas Schmitt wrote:

Patrice Duroux wrote:

option: --preserve=mode
cp: preserving permissions for '/tmp/test.sh': Operation not supported exitcode: 1
[...]
It says that the operation is not supported but still the mode of the
copy is ok.

Maybe it sees ACL at the source file and your /tmp filesystem cannot
do ACL ?

I was thinking something similar, but the "ls -l ./test.sh" did not
show any markup indicating ACL. I would have expected to see a
punctuation character after the permissions (. or + or something)
if that were the case.

Try with setfacl(1) whether files in the /tmp directory accept non-trivial ACLs, like

touch /tmp/x
setfacl -m u:1234:w /tmp/x

The inquiry by

getfacl /tmp/x

should then report among others a line:

user:1234:-w-

It certainly doesn't hurt to check. More information is better in this
case.

She may need to install the "acl" package to get these commands. It's
not installed by default, at least in bookworm.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Patrice Duroux wrote:

cp: preserving permissions for '/tmp/test.sh': Operation not supported

Greg Wooledge wrote:

I was thinking something similar, but the "ls -l ./test.sh" did not
show any markup indicating ACL.

At least cp calls ACL "permissions". See
https://sources.debian.org/src/coreutils/9.4-3.1/lib/copy-acl.c/?hl=54#L54 After getting return value -1 from copy_acl(), it does:

error (0, errno, _("preserving permissions for %s"), quote (dst_name));

The other two occurences of the error message are not as easy to decode:
https://sources.debian.org/src/coreutils/9.4-3.1/src/copy.c/?hl=1696#L1696
https://sources.debian.org/src/coreutils/9.4-3.1/src/copy.c/?hl=3340#L3340

Other thought:
Maybe chattr(1) attribute "i" can be considered a permission, too.


Have a nice day :)

Thomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Patrice Duroux wrote:

option: --preserve=mode
cp: preserving permissions for '/tmp/test.sh': Operation not supported exitcode: 1
[...]
It says that the operation is not supported but still the mode of the
copy is ok.

Maybe it sees ACL at the source file and your /tmp filesystem cannot
do ACL ?

Try with setfacl(1) whether files in the /tmp directory accept non-trivial ACLs, like

touch /tmp/x
setfacl -m u:1234:w /tmp/x

The inquiry by

getfacl /tmp/x

should then report among others a line:

user:1234:-w-


Have a nice day :)

Thomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jul 09, 2024 at 11:04:14 +0200, Patrice Duroux wrote:

$ cat test.sh
#!/usr/bin/sh

export LANG=C
ls -l ./test.sh
echo "option: -p"
cp -p ./test.sh /tmp
echo "exitcode: "$?
ls -l /tmp/test.sh
rm /tmp/test.sh
for p in mode timestamps ownership ; do
echo "option: --preserve=$p"
cp --preserve=$p ./test.sh /tmp
echo "exitcode: "$?
ls -l /tmp/test.sh
rm /tmp/test.sh
done

On Sid (amd64), I am facing the following:

$ ./test.sh
-rwxr-x--- 1 patrice patrice 300 Jul 9 10:46 ./test.sh
option: -p
cp: preserving permissions for '/tmp/test.sh': Operation not supported exitcode: 1
-rwxr-x--- 1 patrice patrice 300 Jul 9 10:46 /tmp/test.sh

It would be nice to know what directory you're in when you run this.
But what I really need to know is whether that directory is /tmp.
Let's assume it's not.

Your prompt is abbreviated as "$" so I assume you're not running this
script as root. (Otherwise your prompt should have been abbreviated
as "#".) Are you running this as "patrice"? Are you in /home/patrice?

It says that the operation is not supported but still the mode of the
copy is ok.
Is there an issue somewhere?

I can't reproduce your results on a bookworm system (kernel
6.1.0-22-amd64), with /tmp as a regular directory in the / file system,
with drwxrwxrwt permissions.

It's possible that something changed between the bookworm kernel and
your kernel. Or possibly your system has additional "security"
features enabled (SELinux?).

Can you tell us what kernel you're running, whether /tmp is a mountpoint
or a regular directory, what kind of file system it is if it's mounted,
and what its permissions are?

Does the same issue happen with /var/tmp? How about /run/user/1000
or whatever patrice's UID is?

If you make a new directory that's not under /tmp or /var/tmp with
drwxrwxrwx permissions (chmod 777), and try to cp -p a file from your
home directory to that new directory, do you get the same result?

If you make the permissions drwxrwxrwt instead (chmod 1777), do you
get the same result?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jul 09, 2024 at 13:46:12 +0200, Thomas Schmitt wrote:

Hi,

Patrice Duroux wrote:

cp: preserving permissions for '/tmp/test.sh': Operation not supported

Greg Wooledge wrote:

I was thinking something similar, but the "ls -l ./test.sh" did not
show any markup indicating ACL.

At least cp calls ACL "permissions". See
https://sources.debian.org/src/coreutils/9.4-3.1/lib/copy-acl.c/?hl=54#L54 After getting return value -1 from copy_acl(), it does:

error (0, errno, _("preserving permissions for %s"), quote (dst_name));

The other two occurences of the error message are not as easy to decode:
https://sources.debian.org/src/coreutils/9.4-3.1/src/copy.c/?hl=1696#L1696
https://sources.debian.org/src/coreutils/9.4-3.1/src/copy.c/?hl=3340#L3340

Other thought:
Maybe chattr(1) attribute "i" can be considered a permission, too.

I'm assuming she didn't make her script immutable and then forget to
mention it. But who knows?

If we can't figure it out from her replies to our *many* requests for additional information, then my next request would be to strace it,
and see exactly which system call is failing.

Either that, or someone else running sid might speak up and confirm
whether they can reproduce the result.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Patrice Duroux wrote:

user:1234:-w-

So it's not that /tmp would refuse on ACL.

getfacl : suppression du premier « / » des noms de chemins absolus
(sorry for the french output)

The translator to french was not overly capricious. So my school french suffices. Google would help if the text would be more flowery.

In cases where the output language matters more, consider to set the
LANG variable to "C" as prefix to the desired command line:

LANG=C getfacl /tmp/x

or as persistent setting for the particular shell instance

export LANG=C
getfacl /tmp/x


(The message by getfacl(1) refers to the first line of its output
# file: tmp/x
not to the input path.)


Have a nice day :)

Thomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jul 09, 2024 at 19:12:28 +0200, Patrice Duroux wrote:

$ LANG=C strace cp -p test.sh /tmp

[...]

read(6, "# /etc/xattr.conf\n#\n# Format:\n# "..., 4096) = 681
read(6, "", 4096) = 0
close(6) = 0
fgetxattr(4, "system.nfs4_acl", NULL, 0) = 80
fgetxattr(4, "system.nfs4_acl", "\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\247\0\0\0\6OWNER@\0\0\0\0\0", 80) = 80
fsetxattr(5, "system.nfs4_acl", "\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\247\0\0\0\6OWNER@\0\0\0\0\0", 80, 0) = -1 EOPNOTSUPP (Operation not supported)
write(2, "cp: ", 4cp: ) = 4
write(2, "preserving permissions for '/tmp"..., 41preserving permissions for '/tmp/test.sh') = 41
write(2, ": Operation not supported", 25: Operation not supported) = 25 write(2, "\n", 1

At this point, FD 4 is the source file (./test.sh) and FD 5 is the
destination file (/tmp/test.sh).

$ mount | grep patrice
/home/patrice type nfs4 (rw,nosuid,nodev,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=X,local_lock=none,addr=Y)

Looks like the error happens while trying to set the extended attributes
on the destination file. I don't really know how xattr works, but
it looks like it's trying to set an attribute named "system.nfs4_acl"
on a file that's in the /tmp directory.

I can't tell whether this is a bug in cp, or a bug in the kernel.
Someone who understands xattr might be better able to help.

Finally, note that I am a «he» otherwise in French it's generally Patricia for
«her»
:-D

My apologies. Patrice is a feminine name in English.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

(I Cc: patrice.duroux@gmail.com because i see no "LDOSUBSCRIBER" in
the "X-Spam-Status:" header.)

Jumping ahead:

Look into the local file

/etc/xattr.conf

and try what happens if you change

system.nfs4_acl permissions

to

system.nfs4_acl skip

or if you newly insert thie "skip" line if no "system.nfs4_acl" is to see.

----------------------------------------------------------------------
How i came to that proposal:

Patrice Duroux wrote:

$ LANG=C strace cp -p test.sh /tmp

strace is a very good idea.

flistxattr(4, NULL, 0) = 16
flistxattr(4, "system.nfs4_acl\0", 16) = 16

Somehow your file has an extended file attribute "system.nfs4_acl".
Inquire by:

getfattr -d test.sh

(I dimly remember that one needs superuser authority to read "system." attributes. But i cannot find this in man 1 getfattr.)

openat(AT_FDCWD, "/etc/xattr.conf", O_RDONLY) = 6

According to Google this is a configuration file:
https://sources.suse.com/SUSE:SLE-15-SP6:Update:CR/minimal-image/f2d0d3c549d068931c52fb2e94925dd7/INCLUDED/SUSE:SLE-15:GA::attr::efd1f5b9c0b136b5dfc37de3f2d9c977/xattr.conf
...
# How to handle extended attributes when copying between files
...
# Actions:
# permissions - copy when trying to preserve permissions.
# skip - do not copy.
...
system.nfs4_acl permissions

cp sees this configuration file associated to SELinux:

https://sources.debian.org/src/coreutils/9.4-3.1/src/copy.c/?hl=751#L749
/* Exclude SELinux extended attributes that are otherwise handled,
and are problematic to copy again. Also honor attributes
configured for exclusion in /etc/xattr.conf.

fsetxattr(5, "system.nfs4_acl", "\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\247\0\0\0\6OWNER@\0\0\0\0\0", 80, 0) = -1 EOPNOTSUPP (Operation not supported)

Here the error happens while trying to set the attribute.
Shell equivalent is

setfattr -n system.nfs4_acl -v '\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\247\0\0\0\6OWNER@\0\0\0\0\0' /tmp/x

and yields here (even for the superuser and on ext4 filesystem)

setfattr: /tmp/x: Operation not supported

I'm not sure whether the value is a digestible format.
But if i do the same with a name in the "user." namespace i get no error

setfattr -n user.x -v '\0\0\0...lengthy.string.above...' /tmp/x


Have a nice day :)

Thomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jul 10, 2024 at 08:20:23 +0700, Max Nikulin wrote:

On 10/07/2024 02:35, Thomas Schmitt wrote:

Here the error happens while trying to set the attribute.
Shell equivalent is

setfattr -n system.nfs4_acl -v '\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\247\0\0\0\6OWNER@\0\0\0\0\0' /tmp/x

Shell does not interpret backslashes in single (and double) quotes. $'\0...' might be better

You cannot pass raw NUL bytes as an argument to a program. It's
impossible. The argument with a NUL byte in the first position will be
treated as an empty string (zero length).

echo '\026' | xxd -g 1
00000000: 5c 30 32 36 0a \026.

echo $'\026' | xxd -g 1
00000000: 16 0a ..

hobbit:~$ echo $'\000\000ABCDEFG' | hd
00000000 0a |.|
00000001

Thomas's command is *relying* on setfattr interpreting the backslash
sequences, because the shell cannot be allowed to do so.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

i wrote:

setfattr -n system.nfs4_acl -v '\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\247\0\0\0\6OWNER@\0\0\0\0\0' /tmp/x

Max Nikulin wrote:

Shell does not interpret backslashes in single (and double) quotes.

Non-interpretation by the shell was my intention. I wanted the string
to reach setfattr(1) literally.

Inspiration was this line from strace:

fsetxattr(5, "system.nfs4_acl",
"\0\0\0\3\0\0\0\0\0\0\0\0\0\26\1\247\0\0\0\6OWNER@\0\0\0\0\0", 80, 0) = -1


Greg Wooledge wrote:

Thomas's command is *relying* on setfattr interpreting the backslash sequences, because the shell cannot be allowed to do so.

Indeed. The man page supports me modulo artistic freedom.

-v value, --value=value
[...] If the given string is
enclosed in double quotes, the inner string is treated as text. In
that case, backslashes and double quotes have special meanings [...]

I omitted the double quotes but obviously my value was decoded as i
intended:

$ getfattr -d /tmp/x
getfattr: Removing leading '/' from absolute path names
# file: tmp/x
user.x=0sAAAAAwAAAAAAAAAAABYBpwAAAAZPV05FUkAAAAAAAA==

$ base64 -d | hxd
AAAAAwAAAAAAAAAAABYBpwAAAAZPV05FUkAAAAAAAA==
<Ctrl+d>
00000000 : 00 00 00 03 00 00 00 00 00 00 00 00 00 16 01 a7

0 : 0 0 0 3 0 0 0 0 0 0 0 0 0 22 1 167

00000010 : 00 00 00 06 4f 57 4e 45 52 40 00 00 00 00 00
O W N E R @
16 : 0 0 0 6 79 87 78 69 82 64 0 0 0 0 0

This looks much like i would expect from correct decoding of the octal
salad text. (hxd is my own binary dumper for hex, cleartext, and decimal.
In a rogue ISO 9660 filesystem one never knows which byte presentation
brings the decisive insight.)


Have a nice day :)

Thomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Patrice Duroux wrote:

On the other hand, after modifying /etc/xattr.conf to replace: system.nfs4_acl permissions
by:
system.nfs4_acl skip
then test.sh works nicely:

So we now know how to prevent the immediate problem.

Does "system.nfs4_acl" show up in

getfattr -d test.sh

?

Is there a risk to leave /etc/xattr.conf like this?

Given our test results with "system.nfs4_acl" and your success with the
changed configuration, i'd say it is mostly beneficial.

You could of course try to remove this hard-to-digest attribute
from the file:

setfattr -x system.nfs4_acl test.sh

If I am right, this file is provided by libattr1 package and its
content is from upstream: https://git.savannah.nongnu.org/cgit/attr.git/tree/xattr.conf

I probably misinterpreted the comment in coreutils copy.c.
SELinux and xattr.conf are not associated but only handled together in
that piece of code.


There remains the question how your file got this attribute.
Was it created when the filesystem was exported via NFS ?

In the web i find references to a command nfs4_setfacl.
Debian has it in package nfs4-acl-tools:
https://tracker.debian.org/pkg/nfs4-acl-tools
Not very active but present from "old-old-stable" to Sid.

Maybe it is the right package to learn more about the attribute of your
file. Maybe it is even the origin of its existence.


Have a nice day :)

Thomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Patrice Duroux wrote:

$ getfattr -d test.sh
$

One could get the impression that "system." attributes are kept obscure
by developers' intention.

I now found in the man page a few sentences which could be the origin of
my dim (and distorted) memories about this name space:

-m pattern, --match=pattern
Only include attributes with names matching the regular expression
pattern. The default value for pattern is "^user\\.", which
includes all the attributes in the user namespace. Specify "-" for
including all attributes.

So what do you get from this run ?

getfattr -d -m - test.sh

$ nfs4_getfacl test.sh
# file: test.sh
A::OWNER@:rwaxtTcCy
A::GROUP@:rxtcy
A::EVERYONE@:tcy

It seems that
man 5 nfs4_acl
gives explanations of the settings under "ACE FLAGS:".

I expect that nfs4_setfacl -x could remove the offending attribute, if not setfacl -x does.
(I would rather move this file to my directory tree of strange files,
which i keep for testing purposes.)


Have a nice day :)

Thomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Max Nikulin wrote:

Thomas, do you have in your collection of strange files a one moved out of a directory encrypted using fscrypt?

Not yet. I will have to think whether such files pose any particular
backup problem.


Have a nice day :)

Thomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)