question related to cp (-p) and /tmp

[Patrice Duroux]

Hi,

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
option: --preserve=mode
cp: preserving permissions for '/tmp/test.sh': Operation not supported
exitcode: 1
-rwxr-x--- 1 patrice patrice 300 Jul 9 10:47 /tmp/test.sh
option: --preserve=timestamps
exitcode: 0
-rwxr-x--- 1 patrice patrice 300 Jul 9 10:46 /tmp/test.sh
option: --preserve=ownership
exitcode: 0
-rwxr-x--- 1 patrice patrice 300 Jul 9 10:47 /tmp/test.sh

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

Thanks,
Patrice

--
$ apt-cache policy coreutils
coreutils:
Installé : 9.4-3.1
Candidat : 9.4-3.1
Table de version :
*** 9.4-3.1 500
500 https://deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status

$ mount | grep /tmp
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576,inode64)

$ cat /etc/tmpfiles.d/tmp.conf
D /tmp 1777 root root -

$ 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

[Thomas Schmitt]

Hi,

Post by Patrice Duroux
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

[Greg Wooledge]

Post by Thomas Schmitt

Post by Patrice Duroux
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.

Post by Thomas Schmitt
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
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.

[Thomas Schmitt]

Hi,

Post by Greg Wooledge

Post by Patrice Duroux
cp: preserving permissions for '/tmp/test.sh': Operation not supported

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

[Greg Wooledge]

Post by Thomas Schmitt
Hi,

Post by Greg Wooledge

Post by Patrice Duroux
cp: preserving permissions for '/tmp/test.sh': Operation not supported

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
error (0, errno, _("preserving permissions for %s"), quote (dst_name));
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
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.

[Patrice Duroux]

Post by Greg Wooledge
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.

$ LANG=C strace cp -p test.sh /tmp
execve("/usr/bin/cp", ["cp", "-p", "test.sh", "/tmp"], 0x7ffe58e09538 /* 33 vars */) = 0
brk(NULL) = 0x561646694000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2776e92000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=251839, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 251839, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f2776e54000
close(3) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libselinux.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=182504, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 190160, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2776e25000
mmap(0x7f2776e2c000, 114688, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7f2776e2c000
mmap(0x7f2776e48000, 32768, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x23000) = 0x7f2776e48000
mmap(0x7f2776e50000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2b000) = 0x7f2776e50000
mmap(0x7f2776e52000, 5840, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2776e52000
close(3) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libacl.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=38832, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 41008, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2776e1a000
mmap(0x7f2776e1c000, 20480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f2776e1c000
mmap(0x7f2776e21000, 8192, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7f2776e21000
mmap(0x7f2776e23000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0x7f2776e23000
close(3) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libattr.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=26544, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 28696, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2776e12000
mmap(0x7f2776e14000, 12288, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f2776e14000
mmap(0x7f2776e17000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5000) = 0x7f2776e17000
mmap(0x7f2776e18000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5000) = 0x7f2776e18000
close(3) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P~\2\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=1933688, ...}, AT_EMPTY_PATH) = 0
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
mmap(NULL, 1985936, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2776c2d000
mmap(0x7f2776c53000, 1404928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26000) = 0x7f2776c53000
mmap(0x7f2776daa000, 348160, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17d000) = 0x7f2776daa000
mmap(0x7f2776dff000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d1000) = 0x7f2776dff000
mmap(0x7f2776e05000, 52624, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2776e05000
close(3) = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpcre2-8.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 832) = 832
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=633480, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 631688, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f2776b92000
mmap(0x7f2776b94000, 442368, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f2776b94000
mmap(0x7f2776c00000, 176128, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6e000) = 0x7f2776c00000
mmap(0x7f2776c2b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x99000) = 0x7f2776c2b000
close(3) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2776b90000
arch_prctl(ARCH_SET_FS, 0x7f2776b91540) = 0
set_tid_address(0x7f2776b91810) = 195619
set_robust_list(0x7f2776b91820, 24) = 0
rseq(0x7f2776b91e60, 0x20, 0, 0x53053053) = 0
mprotect(0x7f2776dff000, 16384, PROT_READ) = 0
mprotect(0x7f2776c2b000, 4096, PROT_READ) = 0
mprotect(0x7f2776e18000, 4096, PROT_READ) = 0
mprotect(0x7f2776e23000, 4096, PROT_READ) = 0
mprotect(0x7f2776e50000, 4096, PROT_READ) = 0
mprotect(0x561616c18000, 4096, PROT_READ) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2776b8e000
mprotect(0x7f2776eca000, 8192, PROT_READ) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
munmap(0x7f2776e54000, 251839) = 0
statfs("/sys/fs/selinux", 0x7fffbb4e2da0) = -1 ENOENT (No such file or directory)
statfs("/selinux", 0x7fffbb4e2da0) = -1 ENOENT (No such file or directory)
getrandom("\x62\x43\x33\x60\xb7\x6c\xd7\x9a", 8, GRND_NONBLOCK) = 8
brk(NULL) = 0x561646694000
brk(0x5616466b5000) = 0x5616466b5000
openat(AT_FDCWD, "/proc/filesystems", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0444, st_size=0, ...}, AT_EMPTY_PATH) = 0
read(3, "nodev\tsysfs\nnodev\ttmpfs\nnodev\tbd"..., 1024) = 414
read(3, "", 1024) = 0
close(3) = 0
access("/etc/selinux/config", F_OK) = -1 ENOENT (No such file or directory)
geteuid() = 1517
openat(AT_FDCWD, "/tmp", O_RDONLY|O_PATH|O_DIRECTORY) = 3
newfstatat(AT_FDCWD, "test.sh", {st_mode=S_IFREG|0750, st_size=300, ...}, 0) = 0
newfstatat(3, "test.sh", {st_mode=S_IFREG|0750, st_size=300, ...}, 0) = 0
openat(AT_FDCWD, "test.sh", O_RDONLY) = 4
newfstatat(4, "", {st_mode=S_IFREG|0750, st_size=300, ...}, AT_EMPTY_PATH) = 0
openat(3, "test.sh", O_WRONLY|O_TRUNC) = 5
ioctl(5, BTRFS_IOC_CLONE or FICLONE, 4) = -1 EXDEV (Invalid cross-device link)
newfstatat(5, "", {st_mode=S_IFREG|0750, st_size=0, ...}, AT_EMPTY_PATH) = 0
fadvise64(4, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
uname({sysname="Linux", nodename="XXXXXXXXXX", ...}) = 0
copy_file_range(4, NULL, 5, NULL, 9223372035781033984, 0) = -1 EXDEV (Invalid cross-device link)
mmap(NULL, 1056768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2776a8c000
read(4, "#!/usr/bin/sh\n\nexport LANG=C\nls "..., 1048576) = 300
write(5, "#!/usr/bin/sh\n\nexport LANG=C\nls "..., 300) = 300
read(4, "", 1048576) = 0
utimensat(5, NULL, [{tv_sec=1720514858, tv_nsec=250366226} /* 2024-07-09T10:47:38.250366226+0200 */, {tv_sec=1720514761, tv_nsec=246516944} /* 2024-07-09T10:46:01.246516944+0200 */], 0) = 0
fchmod(5, 0100750) = 0
flistxattr(4, NULL, 0) = 16
flistxattr(4, "system.nfs4_acl\0", 16) = 16
openat(AT_FDCWD, "/etc/xattr.conf", O_RDONLY) = 6
newfstatat(6, "", {st_mode=S_IFREG|0644, st_size=681, ...}, AT_EMPTY_PATH) = 0
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
) = 1
close(5) = 0
close(4) = 0
munmap(0x7f2776a8c000, 1056768) = 0
lseek(0, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
close(0) = 0
close(1) = 0
close(2) = 0
exit_group(1) = ?
+++ exited with 1 +++

$ cat /etc/xattr.conf
# /etc/xattr.conf
#
# Format:
# <pattern> <action>
#
# Actions:
# permissions - copy when trying to preserve permissions.
# skip - do not copy.

system.nfs4_acl permissions
system.nfs4acl permissions
system.posix_acl_access permissions
system.posix_acl_default permissions
trusted.SGI_ACL_DEFAULT skip # xfs specific
trusted.SGI_ACL_FILE skip # xfs specific
trusted.SGI_CAP_FILE skip # xfs specific
trusted.SGI_DMI_* skip # xfs specific
trusted.SGI_MAC_FILE skip # xfs specific
xfsroot.* skip # xfs specific; obsolete
user.Beagle.* skip # ignore Beagle index data
security.evm skip # may only be written by kernel
afs.* skip # AFS metadata and ACLs

$ 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)

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

[Greg Wooledge]

Post by Patrice Duroux
$ LANG=C strace cp -p test.sh /tmp

[...]

Post by Patrice Duroux
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
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).

Post by Patrice Duroux
$ 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.

Post by Patrice Duroux
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.

[Patrice Duroux]

Post by Greg Wooledge
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.

That is more clear to me now. And so I can confirm that copying to other
destination that is a local disk device gives me the same message and exitcode:

$ LANG=C cp -p test.sh /home2/patrice/ ; echo $?
cp: preserving permissions for '/home2/patrice/test.sh': Operation not supported
1

$ mount | grep home2
/dev/sdb7 on /home2 type ext4 (rw,relatime,stripe=32751)

I should have tested this also.

Post by Greg Wooledge
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.

Just for the story, the current kernel on this system is:

$ uname -srvmo
Linux 6.9.8-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.8-1 (2024-07-07) x86_64 GNU/Linux

so probably it should be reboot at some point and switch for instance
to linux-image-6.9.8-amd64 that is already installed.

Many thanks to all!

[Thomas Schmitt]

Hi,

(I Cc: ***@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.

----------------------------------------------------------------------

Post by Patrice Duroux
$ LANG=C strace cp -p test.sh /tmp

strace is a very good idea.

Post by Patrice Duroux
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.)

Post by Patrice Duroux
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.

Post by Patrice Duroux
fsetxattr(5, "system.nfs4_acl",
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

[Max Nikulin]

Post by Thomas Schmitt
Here the error happens while trying to set the attribute.
Shell equivalent is

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

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

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

C-style backslash escapes are interpreted by printf, but besides leading
dash it would be necessary to deal with %-formats.

Sorry, I am familiar enough with NFS and extended file attributes to
reason if cp should copy system.nfs4_acl in this particular case.

[Greg Wooledge]

Post by Thomas Schmitt
Here the error happens while trying to set the attribute.
Shell equivalent is

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.

[Thomas Schmitt]

Hi,

Post by Max Nikulin
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",

Post by Max Nikulin
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

[Max Nikulin]

Post by Greg Wooledge

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.

Thanks. For some reason I believed that either execve or a similar
system call may pass arguments directly without copy relying on
NULL-terminating strings. Even if it were working, started program would
have to obtain actual length e.g. from another argument. Dealing with
high level languages tracking string length last time caused partial
blindness.

Of course, I was unaware of that setfacl may treat escaping internally.

P.S.
Thomas, do you have in your collection of strange files a one moved out
of a directory encrypted using fscrypt? When the directory is locked,
attempts to read file cause "Required key not available" errors. There
is no tool to find what particular key should be added to keyring

https://docs.kernel.org//filesystems/fscrypt.html#encryption-context

Post by Greg Wooledge
It is up to individual filesystems to decide where to store it, but
normally it would be stored in a hidden extended attribute. It should
not be exposed by the xattr-related system calls such as getxattr() and
setxattr()...

so getfattr reports nothing.

[Thomas Schmitt]

Hi,

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

[Patrice Duroux]

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:
$ ./test.sh
-rwxr-x--- 1 patrice patrice 300 Jul 9 10:46 ./test.sh
option: -p
exitcode: 0
-rwxr-x--- 1 patrice patrice 300 Jul 9 10:46 /tmp/test.sh
option: --preserve=mode
exitcode: 0
-rwxr-x--- 1 patrice patrice 300 Jul 10 08:32 /tmp/test.sh
option: --preserve=timestamps
exitcode: 0
-rwxr-x--- 1 patrice patrice 300 Jul 9 10:46 /tmp/test.sh
option: --preserve=ownership
exitcode: 0
-rwxr-x--- 1 patrice patrice 300 Jul 10 08:32 /tmp/test.sh

Is there a risk to leave /etc/xattr.conf like this?
This file also has a line regarding 'system.nfs4acl'.
Is this for any compatibility?

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

Post by Thomas Schmitt
Hi,
the "X-Spam-Status:" header.)
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.
----------------------------------------------------------------------

Post by Patrice Duroux
$ LANG=C strace cp -p test.sh /tmp

strace is a very good idea.

Post by Patrice Duroux
flistxattr(4, NULL, 0) = 16
flistxattr(4, "system.nfs4_acl\0", 16) = 16

Somehow your file has an extended file attribute "system.nfs4_acl".
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.)

Post by Patrice Duroux
openat(AT_FDCWD, "/etc/xattr.conf", O_RDONLY) = 6

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
...
# permissions - copy when trying to preserve permissions.
# skip - do not copy.
...
system.nfs4_acl permissions
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.

Post by Patrice Duroux
fsetxattr(5, "system.nfs4_acl",
EOPNOTSUPP (Operation not supported)

Here the error happens while trying to set the attribute.
Shell equivalent is
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

[Patrice Duroux]

Sorry for my direct answer.

---------- Forwarded message ---------
De : Patrice Duroux <***@gmail.com>
Date: mar. 9 juil. 2024 à 14:07
Subject: Re: question related to cp (-p) and /tmp
To: Thomas Schmitt <***@gmx.net>


Hi Thomas,

Thanks!
Here is for the source file of the copy:

$ getfacl test.sh
# file: test.sh
# owner: patrice
# group: patrice
user::rwx
group::r-x
other::---

I do not see any specific ACL here.

And here it is for your suggestion:

$ touch /tmp/x
$ setfacl -m u:1234:w /tmp/x
$ getfacl /tmp/x
getfacl : suppression du premier « / » des noms de chemins absolus
# file: tmp/x
# owner: patrice
# group: patrice
user::rw-
user:1234:-w-
group::r--
mask::rw-
other::r--

(sorry for the french output)

Post by Thomas Schmitt
Hi,

Post by Patrice Duroux
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
user:1234:-w-
Have a nice day :)
Thomas

[Greg Wooledge]

Post by Patrice Duroux
$ 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
$ ./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?

Post by Patrice Duroux
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?

[Thomas Schmitt]

Hi,

Post by Thomas Schmitt
user:1234:-w-

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

Post by Thomas Schmitt
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

[Thomas Schmitt]

Hi,

system.nfs4_acl permissions
system.nfs4_acl skip

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
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

[Patrice Duroux]

Post by Thomas Schmitt
So we now know how to prevent the immediate problem.
Does "system.nfs4_acl" show up in
getfattr -d test.sh
?

$ getfattr -d test.sh
$
And this is the same regardless the value (permissions or skip) for
system.nfs4_acl in /etc/xattr.conf

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

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

So nothing more interesting to me despite my ignorance on NFS4.

Post by Thomas Schmitt
Hi,

system.nfs4_acl permissions
system.nfs4_acl skip

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
setfattr -x system.nfs4_acl test.sh

If I am right, this file is provided by libattr1 package and its
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.
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

[Thomas Schmitt]

Hi,

Post by Patrice Duroux
$ 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

Post by Patrice Duroux
$ nfs4_getfacl test.sh
# file: test.sh

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