> Didier Kryn wrote:
>> Hendrik Boom a ecrit :
>>>>> software that isn't properly packaged as a .deb, but instead has an
>>>>> "installer" that needs to be run as root.
> 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.
>
> In real life I have encountered sysadmins who have casually modified
> modules, python in this case but it could have been other, in /usr/lib
> outside of the package manager or any tracking.  Then later normal
> machine upgrades were broken because newer modules were broken by
> upgrading older ones.  If those had been made into /usr/local instead
> it would have been both visible and would not have been broken by
> normal system upgrades.
>
> Being more than twice burned I am extremely shy now...
>
>>>>      If the installer must be run as root, it is precisely because it needs
>>>> to install software in /usr.
> 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.
>
>>> Such software should be installing to /opt, but might not.
>>      Installing application and configuration files in /opt is a possibility,
>> but what to do with man page, application launcher, entry in the application
>> menu? Installing in /opt does not require to mount /usr readonly. Just
>> create a particular user account for /opt and use it to install. Even one
>> user and one subdir per application.
> Although I am not fully warmed up to /opt even after all of these
> years for each of these questions there is a strategy to handle it.
> PATH, MANPATH, desktop launcher files, and so forth.  But those are
> all already set up for /usr/local by default.  /opt by the nature of
> it being outside of the normal system then requires everything to be
> set up for it.  Which is possible and easily done.  But then also must
> be done if used.
>
>>>>      I have written such a software, called hopman. This discussion suggests
>>>> me that I should provide the option to install it in a user's directory,
>>>> without the need to be root, rather than install it system-wide.
> I would say yes.  If it is intended to be installed outside of being
> packaged for the system then it should be easily installed both by
> root (or the classic group staff) in /usr/local or by the user as
> non-root installed into the user's $HOME.
>
> Back in 2019 Didier Kryn wrote:
>      > cd hopman/hopman-1.0
>      > make && make install # You must be root to install
>      > Installed files: /usr/bin/hopman, ...
>
> I didn't follow things beyond this so do not know how things evolved,
> and it isn't fair of me to reach back into the original if it has
> improved and evolved since then.  Sorry.  My bad.  But in the above it
> really should install that into /usr/local/bin (or sbin) by default
> instead of /usr/bin.
>
> For my own environment I would run that as myself in group staff which
> can write to /usr/local/bin without root.  I would run it.  It would
> fail.  I would notice that it was trying to install into /usr/bin.  I
> would review and inspect.  I would then make adjustments so that on my
> system it installed into /usr/local.  Having a read-only /usr in order
> to detect these issues by preventing them is useful.  In my case
> readonly is achieved by not being root.  But since we are training a
> new generation that one must be root for everything then mounting
> /usr read-only kicks the can down the road and pushes the problem
> around to a different place.  But root can always remount it
> read-write.  And the arms conflict continues.  Is Qubes the logical
> conclusion?
>
>      https://www.qubes-os.org/
>
> I also do not know the design of this particular tool hopman.  It may
> require by the nature of it an installation into the root file system
> at the system level.  For example if it needs to run as a root level
> daemon from boot time onward.  I didn't look.  Sorry.  In which case
> that will require at least hooking it into the root file system.  For
> a utility such as hopman I rather expect it might require it.  But for
> many programs they don't and everything could be installed into either
> /usr/local/bin globally or $HOME/bin for the user locally.
>
>>>>> software that is properly packaged, but has components that run as root
>>>>> but do stuff with /usr outside my expectations.
>>>>      Do you mean a package from a Debian repository which would install a
>>>> trojan horse in /usr?
>>> Packages from other sources that are built for Debian but aren't part of
>>> Debian.
>>      For these ones my personal attitude is binary: either I trust them or I
>> don't, not half. Anyway, is there a difference wether the Trojan horse is in
>> /usr or /opt ? Which matters is rather the permissions it has, then at first
>> glance, creating an account per application seems a good practice.
> Trust is something that must be earned.  I trust packaged software
> when the OS packaging as a Policy that protects us.  But with so many
> people creating software there are a lot of untrusted new sources.  I
> wish to provide a safety net so that new untested software can be used
> in safe ways where I am still protected.  Allowing it to gain trust.
>
> I guess I wrote a too long rant...