:: [DNG] Group for /usr/local (was Re:…
Top Page
Delete this message
Reply to this message
Author: Olaf Meeuwissen
Date:  
To: dng
Old-Topics: Re: [DNG] merged /usr breakage
Subject: [DNG] Group for /usr/local (was Re: merged /usr breakage)
Hi Ken, Hendrik,

Ken Dibble <ken@???> writes:

> On 1/7/22 8:59 AM, Hendrik Boom wrote:
>> On Fri, Jan 07, 2022 at 11:44:59AM +0100, Didier Kryn wrote:
>>> Le 07/01/2022 à 10:18, Didier Kryn a écrit :
>>>> Le 06/01/2022 à 22:00, Bob Proulx via Dng a écrit :
>>>>> Immediately I think of all of those script "installers" that
>>>>> request the user do this and similar to install their software as
>>>>> root this way.
>>>>>
>>>>>    wget -O- http:/example.com/foo.sh | bash

>>>>>
>>>>> How many projects do this? Hundreds? Thousands?
>>>>>
>>>>> In real life I have encountered many CAD/EDA tool vendors with
>>>>> installation scripts that casually make system modifications not
>>>>> knowing what they do. I try to keep those contained.
>> If I recall correctly, the manufacturer-supplied printer driver for the
>> Brother HL 3170CDW laser printer does this.


The Docker, Kubernetes, Helm and RKE utilities do this to. It seems to
be fairly common for Go applications as well.

>>>>> Or into /usr/local which now requires root. Back in the better
>>>>> days of Debian it used to be possible for a user of group staff
>>>>> to install into /usr/local without full superuser access. But
>>>>> that's gone from the installation now.
>>>>>
>>>>> https://bugs.debian.org/484841#62
>>>>>
>>>>> Since that has been removed in favor of using full root for
>>>>> everything it removes a useful safety net layer. For example
>>>>> this statement.
>>>>>
>>>>> Russ Allbery writes in comment #77 in favor of using full
>>>>> root instead of a more limited group staff.
>>>>>
>>>>> I would prefer to drop the writeability of /usr/local by
>>>>> staff personally. I don't think it serves much useful
>>>>> purpose these days given the existence of tools like sudo,
>>>>> and where it does, I think we can work out a transition plan
>>>>> that will make it relatively easy for sites to recreate the
>>>>> concept.
>>>>>
>>>>> And the vote went against it. So it's gone now. It's root only.
>>>>> Sigh. On my systems I recreate the group staff concept and
>>>>> implementation. Because I do find it useful.
>> My chimaera system says
>>
>> hendrik@midwinter:~$ ls /usr/local -l
>> total 36
>> drwxrwsr-x  2 root    staff 4096 Jun  1  2021 bin
>> drwxrwsr-x  2 root    staff 4096 Jul  9  2018 etc
>> drwxrwsr-x  2 root    staff 4096 Jul  9  2018 games
>> drwxrwsr-x  2 root    staff 4096 Jul  9  2018 include
>> drwxrwsr-x  4 root    staff 4096 Oct  5 08:27 lib
>> lrwxrwxrwx  1 root    staff    9 Jul  9  2018 man -> share/man
>> drwxr-sr-x 10 hendrik staff 4096 Jun  1  2021 racket
>> drwxrwsr-x  2 root    staff 4096 Jul  9  2018 sbin
>> drwxrwsr-x  9 root    staff 4096 Oct  5 08:21 share
>> drwxrwsr-x  2 root    staff 4096 Jul  9  2018 src

>>
>> so it looks as if 'staff' is still alive.
>> I certainly didn't set up a 'staff' account myself.


Hendrik, did you upgrade this system from beowulf (or earlier)? If so,
that's where the staff group was created.

> Just another data point.
>
> kdibble@thinkstation:~$ ls -l /usr/local
> total 32
> drwxr-xr-x  2 root root 4096 Oct 14 08:23 bin
> drwxr-xr-x  2 root root 4096 Oct 14 08:23 etc
> drwxr-xr-x  2 root root 4096 Oct 14 08:23 games
> drwxr-xr-x  2 root root 4096 Oct 14 08:23 include
> drwxr-xr-x  3 root root 4096 Dec  4 18:59 lib
> lrwxrwxrwx  1 root root    9 Oct 14 08:23 man -> share/man
> drwxr-xr-x  2 root root 4096 Oct 14 08:23 sbin
> drwxr-xr-x 10 root root 4096 Oct 20 11:37 share
> drwxr-xr-x  2 root root 4096 Oct 14 08:23 src


Ken, is this on a chimaera install? As opposed to an upgrade.

It's group root on my daedalus install (used the 5.0.preview-20211220
installer) but I really would have liked it to be staff out-of-the-box.
The staff group still exists, by the way.

Guess I'll have some fixing up to do.

adduser olaf staff
chgrp --recursive staff /usr/local
chmod --recursive g+w /usr/local
find /usr/local -type d -exec chmod g+s '{}' \;

together with a little /etc/apt/apt.conf.d/ snippet like

DPkg::Post-Invoke { "chgrp -R staff /usr/local; chmod -R g+w /usr/local; find /usr/local -type d -exec chmod g+s '{}' \;"; };

ought to keep things the way I prefer them. The snippet uses -R instead
of the more descriptive --recursive for brevity.

Note that the above is simplistic. If you have anything that requires a
specific group and/or permissions, such specifics will be clobbered by
the next apt or dpkg information that modifies your installed packages.

Hmm, on checking before and after states, I noticed that before there
was a /usr/local/share/fonts/ with group staff and the setuid bit for
the group set. There was also a .uuid file in there.

  drwxrwsr-x   2 root     staff        4096 Jan  6 12:27 /usr/local/share/fonts
  -rw-r--r--   1 root     staff          36 Jan  6 12:50 /usr/local/share/fonts/.uuid


All of the above has been checked and tested on a clean, minimal install
of daedulus just a few days ago. That fonts directory was added by the
installation of xserver-xorg.

Hmm, hmm, now I notice dpkg-statoverride ... That's for another time,
maybe.

Hope this helps,
--
Olaf Meeuwissen                    FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join