[MacPorts] #60928: admin user (and ditto group member) no longer has the corresponding permissions?!
MacPorts
noreply at macports.org
Fri Jul 31 09:08:21 UTC 2020
#60928: admin user (and ditto group member) no longer has the corresponding
permissions?!
---------------------------+--------------------
Reporter: RJVB | Owner: (none)
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: | Keywords:
Port: xterm, mrxvt |
---------------------------+--------------------
Description changed by RJVB:
Old description:
> <preamble> >>>>\\
> I have long used Unix permissions principles to ensure direct access to
> certain non-crucial "system" locations from my admin account but not from
> standard user accounts, simply by setting group ownership and rwx access
> for directories to the admin group.
>
> I have 2 admin accounts, my regular account plus another one that I keep
> as close to "stock" as possible and that we shall call `adplus` here. NB:
> my "regular account" is indeed an admin-level account.
>
> I am still running OS X (sic) 10.9.5 so anything that follows cannot be
> due to SIP and related "niceties". Evidently, this system hasn't seen any
> update love from Apple for quite some time now, and I haven't been doing
> any tweaking myself that I can think of (aka remember; uptime was 19d
> when I noticed my issue and nowadays that's long enough to forget
> details... esp. since whatever changed happened during the much longer
> uptime before that). I had been installing the dependencies of `port:e17`
> (with `sudo port -ns install e17`) just before I noticed my issue, but I
> am not certain when I had exploited my "admin" trick for the last time
> before that.
> \\<<<< </preamble>
>
> The issue: when running a shell in the xterm emulator (or `mrxvt`) I can
> no longer access directories that I should be able to access because of
> their group ownership & permissions. Other X11-based terminal emulators
> (like xfce4-terminal) do not show this problem, and the `adplus` account
> is not affected either` No issues either when I connect over ssh from a
> remote linux host. However, any process launched from that xterm (or
> mrxvt) will inherit the permissions restrictions. Group membership of the
> affected account hasn't changed, and it can still use `sudo` for
> instance.
>
> I am not seeing any log entries that are related to rejected access to
> these privileged directories, and AFAICT Apple's xattr-based ACL
> permissions are not involved either.
>
> Fortunately I am no longer using xterm as my daily console emulator (I do
> most of my terminal/shell work under X11) but my X11 work environment was
> in fact set up through a single xterm, which is why I discovered the
> issue. (I would probably have discovered it a lot sooner if my `sudo`
> ability had been affected.)
>
> I have no idea at how this issue can even be possible on a standard Unix,
> nor what the terminal emulator could even have to say over whether a
> child process can enjoy the full range of its intended permissions or
> not. But by now it's pretty clear that among the terminal emulators I
> tested the issue only occurs with these two. A `defect` ticket thus seems
> justified, if not only with the hope that someone more knowledgeable
> about OS X specifics can help understand what goes wrong and where (is
> Brandon Allbery still around?)
New description:
<preamble> >>>>\\
I have long used Unix permissions principles to ensure direct access to
certain non-crucial "system" locations from my admin account but not from
standard user accounts, simply by setting group ownership and rwx access
for directories to the admin group.
I have 2 admin accounts, my regular account plus another one that I keep
as close to "stock" as possible and that we shall call `adplus` here. NB:
my "regular account" is indeed an admin-level account.
I am still running OS X (sic) 10.9.5 so anything that follows cannot be
due to SIP and related "niceties". Evidently, this system hasn't seen any
update love from Apple for quite some time now, and I haven't been doing
any tweaking myself that I can think of (aka remember; uptime was 19d when
I noticed my issue and nowadays that's long enough to forget details...
esp. since whatever changed happened during the much longer uptime before
that). I had been installing the dependencies of `port:e17` (with `sudo
port -ns install e17`) just before I noticed my issue, but I am not
certain when I had exploited my "admin" trick for the last time before
that.
\\<<<< </preamble>
The issue: when running a shell in the xterm emulator (or `mrxvt`) I can
no longer access directories that I should be able to access because of
their group ownership & permissions. Other X11-based terminal emulators
(like xfce4-terminal) do not show this problem, and the `adplus` account
is not affected either. No issues either when I connect over ssh from a
remote linux host. However, any process launched from that xterm (or
mrxvt) will inherit the permissions restrictions. Group membership of the
affected account hasn't changed, and it can still use `sudo` for instance.
I am not seeing any log entries that are related to rejected access to
these privileged directories, and AFAICT Apple's xattr-based ACL
permissions are not involved either.
Fortunately I am no longer using xterm as my daily console emulator (I do
most of my terminal/shell work under X11) but my X11 work environment was
in fact set up through a single xterm, which is why I discovered the
issue. (I would probably have discovered it a lot sooner if my `sudo`
ability had been affected.)
I have no idea at how this issue can even be possible on a standard Unix,
nor what the terminal emulator could even have to say over whether a child
process can enjoy the full range of its intended permissions or not. But
by now it's pretty clear that among the terminal emulators I tested the
issue only occurs with these two. A `defect` ticket thus seems justified,
if not only with the hope that someone more knowledgeable about OS X
specifics can help understand what goes wrong and where (is Brandon
Allbery still around?)
--
--
Ticket URL: <https://trac.macports.org/ticket/60928#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list