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...
