On Tue, May 16, 2023 at 08:20:33AM -0400, Jeff Layton wrote:
> On Tue, 2023-05-16 at 11:17 +0200, Christian Brauner wrote:
> > On Mon, May 15, 2023 at 01:49:21PM -0400, Jeff Layton wrote:
> > > On Mon, 2023-05-15 at 17:28 +, Trond Myklebust wrote:
> > > > On Mon, 2023-05-15 at 13:11 -0400, Jeff
On Tue, 2023-05-16 at 11:17 +0200, Christian Brauner wrote:
> On Mon, May 15, 2023 at 01:49:21PM -0400, Jeff Layton wrote:
> > On Mon, 2023-05-15 at 17:28 +, Trond Myklebust wrote:
> > > On Mon, 2023-05-15 at 13:11 -0400, Jeff Layton wrote:
> > > > On Mon, 2023-05-15 at 11:50 +, Ondrej Valo
On Mon, May 15, 2023 at 01:49:21PM -0400, Jeff Layton wrote:
> On Mon, 2023-05-15 at 17:28 +, Trond Myklebust wrote:
> > On Mon, 2023-05-15 at 13:11 -0400, Jeff Layton wrote:
> > > On Mon, 2023-05-15 at 11:50 +, Ondrej Valousek wrote:
> > > > Hi Paul,
> > > >
> > > > Ok first of all, thank
ysg>
From: Paul Eggert
Sent: Monday, May 15, 2023 11:32:00 PM
To: Ondrej Valousek
Cc: Gnulib bugs
Subject: Re: [PATCH] fix NFSv4 acl detection on F39
On 2023-05-15 12:43, Ondrej Valousek wrote:
> You feed listxattr() with a buffer sized like trivial_NFS4_attr_b
On 2023-05-15 12:43, Ondrej Valousek wrote:
You feed listxattr() with a buffer sized like trivial_NFS4_attr_buf - that just
does not seem to be correct right? That trivial_NFS4_attr_buf serves smth
completely different.
All that listxattr needs is a nonzero-sized buffer. It's OK for a union
ike trivial_NFS4_attr_buf - that just
does not seem to be correct right? That trivial_NFS4_attr_buf serves smth
completely different.
-Original Message-
From: Paul Eggert
Sent: Montag, 15. Mai 2023 19:17
To: Ondrej Valousek
Cc: Gnulib bugs
Subject: Re: [PATCH] fix NFSv4 acl detection on F39
On 2
On Mon, 2023-05-15 at 13:49 -0400, Jeff Layton wrote:
> On Mon, 2023-05-15 at 17:28 +, Trond Myklebust wrote:
> > On Mon, 2023-05-15 at 13:11 -0400, Jeff Layton wrote:
> > > On Mon, 2023-05-15 at 11:50 +, Ondrej Valousek wrote:
> > > > Hi Paul,
> > > >
> > > > Ok first of all, thanks for t
On Mon, 2023-05-15 at 13:11 -0400, Jeff Layton wrote:
> On Mon, 2023-05-15 at 11:50 +, Ondrej Valousek wrote:
> > Hi Paul,
> >
> > Ok first of all, thanks for taking initiative on this, I am unable
> > to proceed on this on my own at the moment.
> > I see few problems with this:
> >
> > 1. Th
On Mon, 2023-05-15 at 17:28 +, Trond Myklebust wrote:
> On Mon, 2023-05-15 at 13:11 -0400, Jeff Layton wrote:
> > On Mon, 2023-05-15 at 11:50 +, Ondrej Valousek wrote:
> > > Hi Paul,
> > >
> > > Ok first of all, thanks for taking initiative on this, I am unable
> > > to proceed on this on
On 2023-05-15 09:43, Ondrej Valousek wrote:
you are not checking for presence of this string in the output of the
listxattr() - unless I am blind.
Don't these lines of file-has-acl.c check for that?
bool nfsv4_acl
= 0 < listsize && have_xattr (XATTR_NAME_NFSV4_ACL, listbuf, lis
On Mon, 2023-05-15 at 11:50 +, Ondrej Valousek wrote:
> Hi Paul,
>
> Ok first of all, thanks for taking initiative on this, I am unable to proceed
> on this on my own at the moment.
> I see few problems with this:
>
> 1. The calculation of the 'listbufsize' is incorrect in your patch. It wil
On 2023-05-15 04:50, Ondrej Valousek wrote:
1. The calculation of the 'listbufsize' is incorrect in your patch. It will
_not_work as you expected and won't limit the number of syscalls (which is why
we came up with this patch, right?). Check with my original proposal, we really
need to check f
ibutes no longer signals the
presence of the actual ACLs, so our code thinks that POSIX acls are present
instead (which makes no sense on NFSv4).
Ondrej
-Original Message-
From: Paul Eggert
Sent: pátek 12. května 2023 21:27
To: Bruno Haible
Cc: bug-gnulib@gnu.org; Ondrej Valousek
Subjec
Oops, that patch has a bug in the rare case where the stack buffer isn't
large enough: it might access freed storage. Fixed by installing the
attached further patch.From f01d8792778b637f7464533ac019e42f58adb310 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 12 May 2023 12:23:49 -0700
Subj
On 2023-05-04 02:36, Bruno Haible wrote:
"Avoid arbitrary limits on the length or number of any data structure,
including file names, lines, files, and symbols, by allocating all data
structures dynamically."
Yes, and I installed into Gnulib the attached patch, which follows that
gu
Ondrej Valousek wrote:
> Well, what if we try to create a decently sized stack buffer (say 256 chars)
> - in 99% we fit into that buffer (actually I can't image we would ever need
> more), and if we do not fit into that buffer we just return 1
This would mean, a program behaves incorrectly just
e and simple to read patch.
-Original Message-
From: Paul Eggert
Sent: Donnerstag, 4. Mai 2023 00:54
To: Ondrej Valousek ; bug-gnulib@gnu.org
Subject: Re: [PATCH] fix NFSv4 acl detection on F39
On 5/2/23 22:44, Ondrej Valousek wrote:
> What's the reason for doing that?
>
On 5/2/23 22:44, Ondrej Valousek wrote:
What's the reason for doing that?
I wanted to save syscalls, not to create more.
Yes, and the approach I suggested will save a syscall in 99.99% of the
cases, as there will be just one llistxattr syscall where your approach
has two. In a very few (pract
[PATCH] fix NFSv4 acl detection on F39
On 5/1/23 19:27, Paul Eggert wrote:
> * Do not use llistxattr (name, NULL, 0). Instead, invoke llistxattr on a
> small (say, 3 KiB) buffer on the stack. Use malloc only if llistxattr
> returns ERANGE, and keep expanding this buffer (via free-then-m
On 5/1/23 19:27, Paul Eggert wrote:
* Do not use llistxattr (name, NULL, 0). Instead, invoke llistxattr on a
small (say, 3 KiB) buffer on the stack. Use malloc only if llistxattr
returns ERANGE, and keep expanding this buffer (via free-then-malloc,
not realloc, since you don't need to save the
What Bruno said, plus:
On 2023-05-01 12:43, Ondrej Valousek wrote:
+/* Return 1 if ATTR is found in the xattr list given by BUF */
+int have_xattr (char const *attr, char *buf, ssize_t buflen)
This returns 1 or 0 so let's have it return bool instead. Also, it
doesn't modify the buffer (or at
Hi Ondrej,
I leave the semantic evaluation of the patch to Paul.
But I would nevertheless point out:
- Freeing an object sometimes in the caller and sometimes in the
callee (function have_xattr) is an invitation for memory bugs
to appear in future changes. It would be better to keep the
Sending the other proposed patch fixing the NFSv4 acl detection on Fedora39.
It's bit longer, but I think should be better.
Please review.
---
lib/file-has-acl.c | 60 +-
1 file changed, 49 insertions(+), 11 deletions(-)
diff --git a/lib/file-has-acl.c
On 2023-04-29 09:08, Ondrej Valousek wrote:
The other (perhaps better?) approach would be to call listxattr() call at the
beginning to see what we are up to actually (in single go we would able to
detect posix and nfsv4 attrs)
The disadvantage would be slightly bigger patch, but we would defini
this sound?
Zasláno z Outlooku pro Android<https://aka.ms/AAb9ysg>
From: Paul Eggert
Sent: Saturday, April 29, 2023 8:35:06 AM
To: Ondrej Valousek
Cc: bug-gnulib@gnu.org
Subject: Re: [PATCH] fix NFSv4 acl detection on F39
On 2023-04-28 13:38, Ondrej Valousek w
On 2023-04-28 13:38, Ondrej Valousek wrote:
On newer systems like Fedora 39, we can't distinguish from the
getxattr(,XATTR_NAME_POSIX_ACL_*,,)
which filesystem we are on. The call return either success or ENODATA.
Does getxattr (name, XATTR_NAME_NFSV4_ACL, xattr, sizeof xattr) also
have this
On newer systems like Fedora 39, we can't distinguish from the
getxattr(,XATTR_NAME_POSIX_ACL_*,,)
which filesystem we are on. The call return either success or ENODATA.
It never returns ENOTSUP as previously. Is it intentional?
This unfortunately means that we have to check for NFSv4 ACLs all the
27 matches
Mail list logo
