On 12/28/22 01:07, Ondrej Valousek wrote:
I was actually wondering why did not you reuse the suggestion from Andreas:
# define ROUNDUP(x, y) (((x) + (y) - 1) & - (y))
It didn't work when the + overflowed, and it assumed two's complement.
The latter assumption is pretty safe
Paul Eggert
Sent: středa 28. prosince 2022 5:13
To: Ondrej Valousek
Cc: Gnulib bugs
Subject: Re: [PATCH] Basic support for checking NFSv4 ACLs in Linux
Some static checking helped find an off-by-one bug that I introduced to your
Gnulib patch. The bug caused file_has_acl to sometimes incorrectly re
Some static checking helped find an off-by-one bug that I introduced to
your Gnulib patch. The bug caused file_has_acl to sometimes incorrectly
return -1 when given a nontrivial ACL in which a WHOLEN is a multiple of
4. Sorry about that. I installed the attached further patch to fix it.From
On 12/24/22 05:00, Ondrej Valousek wrote:
I do not know which code referenced deny ACE for "EVERYONE@".
This was already in file-has-acl.c under the ACE_GETACL code, used in
Solaris 10 and 11 for ZFS and NFSv4. Its commentary talks about "6 entries".
- I would still reference the who
ave tested it on various ACL enabled NFSv4 servers (Linux/
Solaris/ Netapp) and it seems to work OK.
Thanks,
Ondrej
-Original Message-
From: Paul Eggert
Sent: sobota 24. prosince 2022 0:32
To: Ondrej Valousek
Cc: Gnulib bugs
Subject: Re: [PATCH] Basic support for checking NFSv4 ACLs in Linux
I had some trouble using that patch in GNU Emacs, as emacsclient
wouldn't link. I solved this by moving the new function from
acl-internal.c to file-has-acl.c and making it static (no reason to
pubilsh it that I know of). While doing this I did a more careful review
of the code and came up
Hi Ondrej,
> Thanks for the input, I think it should be OK now, please take a look.
The paperwork being complete now, I have pushed the change for you,
with this ChangeLog entry. Thanks!!
2022-12-22 Ondrej Valousek
file-has-acl: Basic support for checking NFSv4 ACLs in Linux.
Hi Ondrej,
> Thanks for the input, I think it should be OK now, please take a look.
Yes, the patch is now in a form that we could commit into Gnulib. Thank you!
For the semantics, I trust your testing and the discussions you had with
Andreas Grünbacher.
The other point is the copyright
Hi Ondrej,
Still some formatting issues. But now, with formatting nearly right, I'm able
to spot other things too.
> +# define ACE4_WHO_OWNER"OWNER@"
> +# define ACE4_WHO_GROUP"GROUP@"
> +# define ACE4_WHO_EVERYONE "EVERYONE@"
> +
> +# define ACE4_ACCESS_ALLOWED_ACE_TYPE 0
> +# define
Hi Ondrej,
Ondrej Valousek wrote:
> Just sending the modified patch (fixed formatting + few suggestions from
> Andreas included)
> Does it look OK now?
Some formatting issues, still. Details below.
> diff --git a/doc/acl-nfsv4.txt b/doc/acl-nfsv4.txt
> new file mode 100644
> index
Am Mo., 28. Nov. 2022 um 08:29 Uhr schrieb Ondrej Valousek
:
> Hi Andreas,
>
> - I do not quite understand. I did not bother copying the who value into
> extra buffer hence I am using strncmp instead of strcmp and therefore can't
> use strlen. The checks are sufficient there.
Please ask
-gnulib@gnu.org
Subject: Re: [PATCH] Basic support for checking NFSv4 ACLs in Linux
Am Fr., 25. Nov. 2022 um 10:34 Uhr schrieb Andreas Grünbacher :
> Am Do., 24. Nov. 2022 um 18:21 Uhr schrieb Ondrej Valousek
> :
> > Hi GNU lib maintainers,
> >
> > Attaching the final vers
Am Fr., 25. Nov. 2022 um 10:34 Uhr schrieb Andreas Grünbacher :
> Am Do., 24. Nov. 2022 um 18:21 Uhr schrieb Ondrej Valousek
> :
> > Hi GNU lib maintainers,
> >
> > Attaching the final version of patch introducing a basic checks for
> > non-trivial NFSv4 style ACLs.
> > It is substantially longer
Am Do., 24. Nov. 2022 um 18:21 Uhr schrieb Ondrej Valousek
:
> Hi GNU lib maintainers,
>
> Attaching the final version of patch introducing a basic checks for
> non-trivial NFSv4 style ACLs.
> It is substantially longer unfortunately - that's why I put most of the code
> to acl-internal.c where
[CCing Andreas Grünbacher.]
Hi Ondrej,
Thank you very much for working on this, so consistently for a month.
Like you said: "it might not be perfect, but it's far better than what we
have now in there (i.e. nothing)". Therefore I'd like to have your changes
included, for the benefit of coreutils
> I'm not really sure what to do about ACE4_READ_NAMED_ATTRS and
> ACE4_WRITE_NAMED_ATTRS; those are not the same as Linux extended attributes.
> This will need a bit of testing against various NFSv4 servers to give
> reasonable results.
Can we just commit the code as-is without the extra
Am Di., 15. Nov. 2022 um 13:46 Uhr schrieb Ondrej Valousek
:
> > This would correspond to a mode attribute of "--rwx" according to the
> > above statement,
> Well I do not think so as the RFC also states that EVERYONE@ means literally
> everyone (including group and owner), so the above
> This would correspond to a mode attribute of "--rwx" according to the
> above statement,
Well I do not think so as the RFC also states that EVERYONE@ means literally
everyone (including group and owner), so the above example would indeed return
rwxrwxrwx.
Anyhow, would the code I
Am Di., 15. Nov. 2022 um 10:17 Uhr schrieb Ondrej Valousek
:
> I mean from RFC8881:
> " The server that supports both mode and ACL must take care to synchronize
> the MODE4_*USR, MODE4_*GRP, and MODE4_*OTH bits with the ACEs that have
> respective who fields of "OWNER@", "GROUP@", and
Am Di., 15. Nov. 2022 um 10:17 Uhr schrieb Ondrej Valousek
:
> > * If an ALLOW entry has any mask bits set that don't correspond to the UNIX
> > rwx permissions, we don't have a trivial ACL.
> Do we really have to do this?
Of course. For example, an ACL that grants ACE4_WRITE_ACL to anyone
> * If an ALLOW entry has any mask bits set that don't correspond to the UNIX
> rwx permissions, we don't have a trivial ACL.
Do we really have to do this?
I mean from RFC8881:
" The server that supports both mode and ACL must take care to synchronize the
MODE4_*USR, MODE4_*GRP, and MODE4_*OTH
Am Di., 15. Nov. 2022 um 03:45 Uhr schrieb Paul Eggert :
> On 11/14/22 00:16, Ondrej Valousek wrote:
> > The disadvantage is that it pulls back dependency on libacl for some reason
> > (the code does not
> > use libacl at all
>
> Yes, this needs to be fixed somehow, as part of the point of this
On 11/14/22 00:16, Ondrej Valousek wrote:
The disadvantage is that it pulls back dependency on libacl for some reason
(the code does not
use libacl at all
Yes, this needs to be fixed somehow, as part of the point of this Gnulib
module is to not require programs like GNU ls to dynamically
Am Mo., 14. Nov. 2022 um 09:18 Uhr schrieb Ondrej Valousek
:
> Hi Andreas/all
> Would you support the following version of the patch?
We're probably getting there ...
> It is substantially longer unfortunately - that's why I put most of the code
> to acl-internal.c where I think
> it should be
On 2022-11-11 00:40, Ondrej Valousek wrote:
I think I have complete picture now. I also think that eventually I can
eventually fix gnulib (hopefully the gnulib folks stay supportive) as there are
already some pieces of code for AIX that I could possibly reuse.
Thanks for taking this on.
Hi Andreas,
> Historically, I've suggested taking care of these kinds of things in the
> richacl project, but that effort has been shot down upstream, and that
> project has been dead for a long time.
I think I have complete picture now. I also think that eventually I can
eventually fix
Am Mo., 7. Nov. 2022 um 13:45 Uhr schrieb Ondrej Valousek
:
> Hi Andreas,
> Can you please clarify this?
Gnulib commit da6ebc941 ("acl: On Linux, check for acls without
libacl") switched from acl_extended_file to getxattr to avoid a
runtime dependency on libacl. I think that was mainly a benefit
2022 20:37
To: Ondrej Valousek ; Bruno Haible
; bug-gnulib@gnu.org
Cc: Andreas Gruenbacher
Subject: Re: [PATCH] Basic support for checking NFSv4 ACLs in Linux
On 2022-10-31 01:05, Ondrej Valousek wrote:
> I do not quite understand why we are not calling acl_extended_file()
> any more on
On 2022-10-31 01:05, Ondrej Valousek wrote:
I do not quite understand why we are not calling acl_extended_file() any more
on Linux
This was due to a 2015 patch by Andreas Gruenbacher:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=da6ebc941e966141e83591408545224274d0cf0f
that in
ct: Re: [PATCH] Basic support for checking NFSv4 ACLs in Linux
On 2022-10-28 07:33, Ondrej Valousek wrote:
> 2. The 'acl' package (as of today) only supports Posix ACLs and not the NFSv4
> style. And besides, we do not use it anyway on modern Linux distros - see the
> code, instead of calli
On 2022-10-28 07:33, Ondrej Valousek wrote:
2. The 'acl' package (as of today) only supports Posix ACLs and not the NFSv4
style. And besides, we do not use it anyway on modern Linux distros - see the
code, instead of calling acl library, we just call getxattr() function directly.
Is that the
sek
Subject: Re: [PATCH] Basic support for checking NFSv4 ACLs in Linux
Hi Ondrej,
Thanks for the proposed patch.
But before we go into details, I would like to understand the big picture:
1) What is the scenario in which the patch should make a difference?
An NFSv4 volume exported
Hi Ondrej,
Thanks for the proposed patch.
But before we go into details, I would like to understand the big picture:
1) What is the scenario in which the patch should make a difference?
An NFSv4 volume exported from a different machine, and mounted on Linux,
right?
Which OSes
33 matches
Mail list logo
