Re: question related to cp (-p) and /tmp
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
Re: question related to cp (-p) and /tmp
On 10/07/2024 08:48, Greg Wooledge wrote: On Wed, Jul 10, 2024 at 08:20:23 +0700, Max Nikulin wrote: On 10/07/2024 02:35, Thomas Schmitt 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 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 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.
Re: question related to cp (-p) and /tmp
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
Re: question related to cp (-p) and /tmp
> 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 > 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. Le mer. 10 juil. 2024 à 09:11, Thomas Schmitt a écrit : > > Hi, > > Patrice Duroux wrote: > > On the other hand, after modifying /etc/xattr.conf to replace: > > system.nfs4_aclpermissions > > by: > > system.nfs4_aclskip > > 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 >
Re: question related to cp (-p) and /tmp
On the other hand, after modifying /etc/xattr.conf to replace: system.nfs4_aclpermissions by: system.nfs4_aclskip 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 Le mar. 9 juil. 2024 à 21:33, Thomas Schmitt a écrit : > > Hi, > > (I Cc: patrice.dur...@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 >
Re: question related to cp (-p) and /tmp
Hi, Patrice Duroux wrote: > On the other hand, after modifying /etc/xattr.conf to replace: > system.nfs4_aclpermissions > by: > system.nfs4_aclskip > 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
Re: question related to cp (-p) and /tmp
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=0sAwAAABYBpwZPV05FUk== $ base64 -d | hxd AwAAABYBpwZPV05FUk== :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 0010 :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
Re: question related to cp (-p) and /tmp
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 > : 5c 30 32 36 0a \026. > > echo $'\026' | xxd -g 1 > : 16 0a.. hobbit:~$ echo $'\000\000ABCDEFG' | hd 0a|.| 0001 Thomas's command is *relying* on setfattr interpreting the backslash sequences, because the shell cannot be allowed to do so.
Re: question related to cp (-p) and /tmp
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 echo '\026' | xxd -g 1 : 5c 30 32 36 0a \026. echo $'\026' | xxd -g 1 : 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.
Re: question related to cp (-p) and /tmp
Hi, (I Cc: patrice.dur...@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
Re: Re: Re: question related to cp (-p) and /tmp
> 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. > 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!
Re: Re: question related to cp (-p) and /tmp
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.
Re: Re: question related to cp (-p) and /tmp
> 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(0x7f2776e5, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2b000) = 0x7f2776e5
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(0x7f2776c0, 176128, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3,
0x6e000) = 0x7f2776c0
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) =
0x7f2776b9
arch_prctl(ARCH_SET_FS, 0x7f2776b91540) = 0
set_tid_address(0x7f2776b91810) = 195619
set_robust_list(0x7f2776b91820, 24) = 0
r
Re: question related to cp (-p) and /tmp
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
Fwd: question related to cp (-p) and /tmp
Sorry for my direct answer. -- Forwarded message - De : Patrice Duroux Date: mar. 9 juil. 2024 à 14:07 Subject: Re: question related to cp (-p) and /tmp To: Thomas Schmitt 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) Le mar. 9 juil. 2024 à 13:18, Thomas Schmitt a écrit : > > 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 >
Re: question related to cp (-p) and /tmp
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.
Re: question related to cp (-p) and /tmp
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
Re: question related to cp (-p) and /tmp
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.
Re: question related to cp (-p) and /tmp
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
Re: question related to cp (-p) and /tmp
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?
question related to cp (-p) and /tmp
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
