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.

--     Didier