[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