From: Bruno Haible <bruno@clisp.org>
To: Ondrej Valousek <ondrej.valousek.xm@renesas.com>,
bug-gnulib@gnu.org, Paul Eggert <eggert@cs.ucla.edu>
Subject: Re: ACL complexity
Date: Fri, 13 Jan 2023 10:15:11 +0100 [thread overview]
Message-ID: <3915504.t68216eyJU@nimes> (raw)
In-Reply-To: <ea13d345-a80e-580b-42a0-5c0592139087@cs.ucla.edu>
Paul Eggert wrote (when talking about libxattr and such):
> No kidding. This stuff is waaaayy too complicated.
More generally, I find the semantics and the syntax of ACLs on most
systems to be more demanding than what the average command-line user can
grok. While for random features of the OS this would just be a nuisance
that can be ignored, for a feature with impact on security this is a
major problem.
What I mean is:
1) The syntax.
# getfacl /tmp/file
getfacl: Removing leading '/' from absolute path names (<< what is this about?)
# file: tmp/file
# owner: test1
# group: test
user::rw-
user:test3:rw-
group::rw-
mask::rw-
other::---
A sysadmin may understand this, but an average command-line user won't.
Suggestion: Add a mode to 'ls' (not to getfacl, because average users
know about 'ls' only) that displays the same info with explanations.
It doesn't matter if the output is 25 lines instead of 8 lines, in this
mode.
2) The semantics.
What are "effective" permissions
https://tylersguides.com/guides/linux-acl-permissions-tutorial/ ?
Suggestion: Provide a kind of "testing toolbox" to the users, which they
can use to simulate what happens when someone tries to access an existing
or new file, after they have set specific permissions and ACLs.
Bruno
next prev parent reply other threads:[~2023-01-13 9:15 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-04 14:34 [PATCH] Use xattr (Linux) in qcopy-acl.c Ondrej Valousek
2023-01-04 14:46 ` Bruno Haible
2023-01-04 19:29 ` Paul Eggert
2023-01-04 20:54 ` Ondrej Valousek
2023-01-05 1:19 ` Paul Eggert
2023-01-13 9:15 ` Bruno Haible [this message]
2023-01-13 10:03 ` ACL complexity Ondrej Valousek
2023-01-13 11:05 ` Bruno Haible
2023-01-13 11:22 ` Ondrej Valousek
2023-01-05 9:00 ` [PATCH] Use xattr (Linux) in qcopy-acl.c Bruno Haible
2023-01-05 9:05 ` Ondrej Valousek
2023-01-05 10:32 ` Bruno Haible
2023-01-05 19:06 ` Paul Eggert
2023-01-11 9:11 ` Ondrej Valousek
2023-01-12 20:42 ` Bruno Haible
2023-01-13 7:51 ` Bruno Haible
2023-01-13 8:09 ` Bruno Haible
2023-01-13 8:32 ` Ondrej Valousek
2023-01-13 8:46 ` Bruno Haible
2023-01-14 1:52 ` Paul Eggert
2023-01-14 7:26 ` Ondrej Valousek
2023-01-14 7:55 ` Bruno Haible
2023-01-14 8:02 ` Ondrej Valousek
2023-01-13 8:33 ` Bruno Haible
2023-01-13 8:50 ` Bruno Haible
2023-01-30 10:18 ` Bruno Haible
2023-01-05 8:56 ` Bruno Haible
[not found] ` <TYXPR01MB18544D0A5C213BF0204BF0D4D9FD9@TYXPR01MB1854.jpnprd01.prod.outlook.com>
[not found] ` <c1ddff8c-2734-bfa1-11a3-3279ae9e92cb@cs.ucla.edu>
2023-01-12 20:58 ` Bruno Haible
2023-01-12 22:53 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3915504.t68216eyJU@nimes \
--to=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=ondrej.valousek.xm@renesas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).