Hi Didier,

Didier Kryn <kryn@???> writes:

> Le 07/01/2022 à 10:18, Didier Kryn a écrit :
>> Le 06/01/2022 à 22:00, Bob Proulx via Dng a écrit :
>>> 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...
>>
>>     I ignore the rant. But it seems you're my man. I am making some
>> improvements to the package and, since you suggest manpages,
>> launchers and entries for the application menu can be put in
>> /usr/local, I will follow this path. If you could develop on these
>> points it would save me some time.
>>
>>     The program runs with the priviledges of the user. It has a GUI
>> and invokes pmount, xterm and file manager like the user would do
>> from the command line. Only pmount has priviledges. The makefile has
>> a target to uninstall.
>
>
> Concerning installation in /usr/local:
> --------------------------------------
>
>     My first investigations indicate that there is provision in
> Freedesktop.org to put icons and launchers under $HOME/.local, but
> nothing for /usr/local. Therefore the installation of an application
> in /usr/local could include executable, config files and manpages, but
> the icon and the launcher would be per user.
>     Seems /usr/local is honoured by the base system (default PATH and
> default man search path) but is "deprecated" by Freedesktop.
>
>
> Concerning installation in user's space:
> ----------------------------------------
>
>     As written above, Freedesktop enables icons, launchers and
> applications menu in ~/.local . Man will look also by default search
> ~/man if it exists, but, to my knowledge, there is no default user
> directory for executables; it is therefore up to the user to create
> this directory and specify it when installing, which makes
> uninstallation problematic.
>
>     In this case, the installer might force the use of ~/bin and ~/man
> and create them if they don't exist.

If I were you I would make the installation locations configurable, at
least at build time with an option to override at install time.

Don't know if you have any experience with building GNU software from
source but the ./configure command has options to set a whole pile of
locations:

- bindir
- libdir
- mandir
- ...

by default these locations are below a configurable prefixdir that
defaults to /usr/local so you get to install below

- /usr/local/bin
- /usr/local/lib
- /usr/local/man
- /usr/local/...

If the user runs ./configure --prefix=$HOME then everything will end up
below $HOME. If that user also added --mandir=/usr/local/man then only
the manual pages would end up there, everything else still goes below
$HOME.

Often the resulting Makefile allows specifying a staging location, a
destdir, so you can easily bundle the installed result, in a Debian
package for example ;-). Setting destdir to /tmp/test, would install
that $HOME configured build in

- /tmp/test/$HOME/bin
- /tmp/test/$HOME/lib
- /tmp/test/usr/local/man
- /tmp/test/$HOME/...

but at run-time still use the location without the /tmp/test prefix.

Long story short, don't try to decide the final locations but make them
configurable and let the builder decide. Just organize the locations
using things like bindir, libdir, etc and make your code use whatever
was configured at build time.

I realize that autoconf may be less popular than it once was (cmake is
gaining popularity, it seems) but its documentation has a section on the
various installation locations it supports. Perhaps that can serve as a
guide for picking the places you need.

https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/autoconf.html#Installation-Directory-Variables

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