On 2025-01-11 08:48, Pádraig Brady wrote:
The attached gnulib patch does that.
Thanks for fixing that.
On 11/01/2025 13:44, Pádraig Brady wrote:
On 11/01/2025 08:37, Paul Eggert wrote:
On 2025-01-10 06:48, Pádraig Brady wrote:
With the previously discussed ls patch included, we also suppress the error
(while indicating the obtainable security context):
$ src/ls -l /mnt/nfs
total 0
--w---. 1
On 11/01/2025 08:37, Paul Eggert wrote:
On 2025-01-10 06:48, Pádraig Brady wrote:
With the previously discussed ls patch included, we also suppress the error
(while indicating the obtainable security context):
$ src/ls -l /mnt/nfs
total 0
--w---. 1 padraig padraig 0 Jan 8 20:42 file
I'll
On 2025-01-10 06:48, Pádraig Brady wrote:
With the previously discussed ls patch included, we also suppress the error
(while indicating the obtainable security context):
$ src/ls -l /mnt/nfs
total 0
--w---. 1 padraig padraig 0 Jan 8 20:42 file
I'll push that ls patch now.
Thanks, but I'm
On 10/01/2025 04:46, Paul Eggert wrote:
On 2025-01-09 05:29, Pádraig Brady wrote:
over NFS with unreadable files
you can GET the security.selinux xattr, but you can't LIST any xattrs:
Ouch again
Also there was a change since coreutils v9.5 where we don't call the GET,
Yes, that is fo
On 2025-01-09 05:29, Pádraig Brady wrote:
over NFS with unreadable files
you can GET the security.selinux xattr, but you can't LIST any xattrs:
Ouch again
Also there was a change since coreutils v9.5 where we don't call the GET,
Yes, that is for efficiency in the common case where the
I've CC'd linux-nfs in case anyone there has some insight
as to why listxattr() is more restrictive on NFS than locally,
returning EACCES for files without read access. Details below...
On 09/01/2025 04:55, Paul Eggert wrote:
Thanks, but is this part of the change needed?
+ else if (f->acl_ty
Thanks, but is this part of the change needed?
+ else if (f->acl_type == ACL_T_UNKNOWN)
+modebuf[10] = '?';
I thought modebuf[10] was already '?' at that point.
On 08/01/2025 19:41, Paul Eggert wrote:
On 2025-01-08 06:24, Pádraig Brady wrote:
The EACCES is returned from both llistxattr and listxattr.
Is flistxattr the same?
You need read permission to get xattrs on local or nfs.
Isn't it more complicated than that, for local file systems? Here's
On 2025-01-08 06:24, Pádraig Brady wrote:
The EACCES is returned from both llistxattr and listxattr.
Is flistxattr the same?
You need read permission to get xattrs on local or nfs.
Isn't it more complicated than that, for local file systems? Here's what
I observe on Fedora 41 with a local
On 05/12/2024 21:56, Paul Eggert wrote:
On 2024-12-04 09:10, Ioanna Alifieraki wrote:
When ls -la is run on NFS shares, get_aclinfo() in gnulib is eventually
invoked. This calls listxattr, which, as expected, returns -1 and sets
errno when the user lacks permissions for a directory.
That's not
On 2024-12-04 09:10, Ioanna Alifieraki wrote:
When ls -la is run on NFS shares, get_aclinfo() in gnulib is eventually
invoked. This calls listxattr, which, as expected, returns -1 and sets
errno when the user lacks permissions for a directory.
That's not what I expect, any more than I'd expect
Hi,
I’m writing to report unexpected behavior in the output of ls on NFS
shares, which appears to be related to the listxattr in gnulib.
When a user lacks permissions to access certain directories on an NFS
share, ls -la produces "Permission denied" errors for those directories
and then the out
13 matches
Mail list logo
