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.
