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/xShell does not interpret backslashes in single (and double) quotes. $'\0...' might be betterYou 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.