bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
* Improve support for ACLs in coreutils (ls & chmod) following the Solaris way
@ 2023-01-16 15:03 Ondrej Valousek
  2023-01-16 17:23 ` Bruno Haible
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Ondrej Valousek @ 2023-01-16 15:03 UTC (permalink / raw)
  To: coreutils@gnu.org; +Cc: bug-gnulib@gnu.org

Hi,

As per our conversation with Bruno I was thinking if it would make a sense to extend support of ACLs in gnulib/coreutils, mainly covering "ls" (1st stage) and "chmod" (2nd stage)  with the goal to have the ACLs better understandable for end users.  

For "ls" we would:
- Introduce a new flag "-V" that would work like "-l" but also append text interpretation of ACLs as in Solaris, i.e.:
# ls -V 
total 7
-rw-r--r--+  1 root     root           5 Jan  4 09:11 acl
            user:ondrej:rwx-----------:-------:allow
                 owner@:rw-p--aARWcCos:-------:allow
                 group@:r-----a-R-c--s:-------:allow
              everyone@:r-----a-R-c--s:-------:allow

For "chmod" we would add new option "A" that would allow modify ACEs like in Solaris:
# chmod A+user:marks:rw- file.1

Technical implementation:
- I'd like to support NFSv4 ACLs, but since we have no library for it, then we would need to provide some parsing code for it and stick in Gnulib - we have something in "file-has-acl.c" already and it would be a good starting point.
- file_has_acl() function would need to be modified slightly to return 2 in case NFSv4 acls were found (this is backward compatible).

For Posix acls we would use the existing libacl.

Is this something I would find support in both coreutils and Gnulib?
Thanks

Ondrej




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Improve support for ACLs in coreutils (ls & chmod) following the Solaris way
  2023-01-16 15:03 Improve support for ACLs in coreutils (ls & chmod) following the Solaris way Ondrej Valousek
@ 2023-01-16 17:23 ` Bruno Haible
  2023-01-16 19:15 ` Pádraig Brady
  2023-01-17 23:28 ` Paul Eggert
  2 siblings, 0 replies; 5+ messages in thread
From: Bruno Haible @ 2023-01-16 17:23 UTC (permalink / raw)
  To: bug-gnulib, Ondrej Valousek; +Cc: coreutils@gnu.org

Ondrej Valousek wrote:
> Is this something I would find support in both coreutils and Gnulib?

Regarding Gnulib: Yes, for code that has its proper place in Gnulib, you
have my support.

Bruno





^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Improve support for ACLs in coreutils (ls & chmod) following the Solaris way
  2023-01-16 15:03 Improve support for ACLs in coreutils (ls & chmod) following the Solaris way Ondrej Valousek
  2023-01-16 17:23 ` Bruno Haible
@ 2023-01-16 19:15 ` Pádraig Brady
  2023-01-16 20:22   ` Bruno Haible
  2023-01-17 23:28 ` Paul Eggert
  2 siblings, 1 reply; 5+ messages in thread
From: Pádraig Brady @ 2023-01-16 19:15 UTC (permalink / raw)
  To: Ondrej Valousek, coreutils@gnu.org; +Cc: bug-gnulib@gnu.org

On 16/01/2023 15:03, Ondrej Valousek wrote:
> Hi,
> 
> As per our conversation with Bruno I was thinking if it would make a sense to extend support of ACLs in gnulib/coreutils, mainly covering "ls" (1st stage) and "chmod" (2nd stage)  with the goal to have the ACLs better understandable for end users.
> 
> For "ls" we would:
> - Introduce a new flag "-V" that would work like "-l" but also append text interpretation of ACLs as in Solaris, i.e.:
> # ls -V
> total 7
> -rw-r--r--+  1 root     root           5 Jan  4 09:11 acl
>              user:ondrej:rwx-----------:-------:allow
>                   owner@:rw-p--aARWcCos:-------:allow
>                   group@:r-----a-R-c--s:-------:allow
>                everyone@:r-----a-R-c--s:-------:allow
> 
> For "chmod" we would add new option "A" that would allow modify ACEs like in Solaris:
> # chmod A+user:marks:rw- file.1
> 
> Technical implementation:
> - I'd like to support NFSv4 ACLs, but since we have no library for it, then we would need to provide some parsing code for it and stick in Gnulib - we have something in "file-has-acl.c" already and it would be a good starting point.
> - file_has_acl() function would need to be modified slightly to return 2 in case NFSv4 acls were found (this is backward compatible).
> 
> For Posix acls we would use the existing libacl.
> 
> Is this something I would find support in both coreutils and Gnulib?
> Thanks

Maybe, though I'm not convinced about adding to ls and chmod.
This would add lots more complexity for parsing ACLs on input and output.

Now saying that, there is some precedence with SELinux attributes
generally integrated through the -Z option.

For completeness, if "additional attributes" manipulation we have:

ACLS: {get,set}facl
Capabilities: {get,set}cap
SELinux: getfattr -m 'selinux' -d,chcon
xattrs: {get,set}fattr
linux extra attributes: {ls,ch}attr

So as we see there are lots of "additional attributes"
with dedicated programs to manipulate them.
What's the big advantage of merging with ls and chmod,
over the current situation of separate utilities?

Also there is the question of whether ACLs are always available.
ext4 or nfs could be mounted with noacl for example, or some file systems
may need acl support enabled with a mount option.

Personally I feel we're exposing lots of complexity here for not much gain.

thanks,
Pádraig


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Improve support for ACLs in coreutils (ls & chmod) following the Solaris way
  2023-01-16 19:15 ` Pádraig Brady
@ 2023-01-16 20:22   ` Bruno Haible
  0 siblings, 0 replies; 5+ messages in thread
From: Bruno Haible @ 2023-01-16 20:22 UTC (permalink / raw)
  To: Ondrej Valousek, Pádraig Brady; +Cc: coreutils, bug-gnulib

Pádraig Brady wrote:
> So as we see there are lots of "additional attributes"
> with dedicated programs to manipulate them.
> What's the big advantage of merging with ls and chmod,
> over the current situation of separate utilities?

In [1] I'm arguing:

  * A feature that has impact on security, and that its users don't
    understand, is a major security problem it itself. If it's too
    easy to misunderstand what effect a specific ACL has, it will cause
    unintended ACLs to be set.

  * Hence efforts should be made that enable the users to understand
    the ACLs that they may set or have set.

  * Most users have no experience with {get,set}facl, {get,set}fattr,
    {ls,ch}attr, only with 'ls' and 'chmod'. Therefore it will be
    easier for them to learn another 'ls' option that to remember three(!)
    other programs getfacl, getfattr, lsattr.

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2023-01/msg00086.html





^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Improve support for ACLs in coreutils (ls & chmod) following the Solaris way
  2023-01-16 15:03 Improve support for ACLs in coreutils (ls & chmod) following the Solaris way Ondrej Valousek
  2023-01-16 17:23 ` Bruno Haible
  2023-01-16 19:15 ` Pádraig Brady
@ 2023-01-17 23:28 ` Paul Eggert
  2 siblings, 0 replies; 5+ messages in thread
From: Paul Eggert @ 2023-01-17 23:28 UTC (permalink / raw)
  To: bug-gnulib

On 1/16/23 07:03, Ondrej Valousek wrote:
> Is this something I would find support in both coreutils and Gnulib?

Works for me.

Though I have to wonder: why isn't this stuff in a library that Gnulib 
and/or coreutils can use? It seems a bit odd to introduce a reasonably 
major security feature like this in Gnulib.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-01-17 23:28 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-16 15:03 Improve support for ACLs in coreutils (ls & chmod) following the Solaris way Ondrej Valousek
2023-01-16 17:23 ` Bruno Haible
2023-01-16 19:15 ` Pádraig Brady
2023-01-16 20:22   ` Bruno Haible
2023-01-17 23:28 ` Paul Eggert

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).