[MacPorts] #60928: admin user (and ditto group member) no longer has the corresponding permissions?!
MacPorts
noreply at macports.org
Fri Jul 31 09:03:28 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:
Keywords: | Port: xterm, mrxvt
--------------------+--------------------------
<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>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list