Hi Ken, Hendrik, Ken Dibble <k...@beckydibble.com> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng