:: Re: [DNG] merged /usr breakage
Forside
Slet denne besked
Besvar denne besked
Skribent: Didier Kryn
Dato:  
Til: dng@lists.dyne.org
Emne: Re: [DNG] merged /usr breakage
Le 05/01/2022 à 23:12, Hendrik Boom a écrit :
> On Wed, Jan 05, 2022 at 09:54:20PM +0100, Didier Kryn wrote:
>> Le 05/01/2022 à 16:11, Hendrik Boom a écrit :
>>> On Wed, Jan 05, 2022 at 12:08:18AM +0100, Didier Kryn wrote:
>>>> Le 04/01/2022 à 23:38, Hendrik Boom a écrit :
>>>>> On Tue, Jan 04, 2022 at 05:09:58PM +0100, Didier Kryn wrote:
>>>>>> There is no utility in splitting the OS in several partitions.
>>>>> Might it make sense to have /usr mounted readonly except when upgradng
>>>>> or installing paackages?
>>>>>
>>>>     What could you fear which makes you want to keep /usr readonly.
>>> software that isn't properly packaged as a .deb, but instead has an
>>> "installer" that needs to be run as root.
>>     If the installer must be run as root, it is precisely because it
>> needs
>> to install software in /usr. You have an alternative: either mount /usr
>> readwrite and install it, or keep /usr readonly and not install it.
>> Keeping
>> /usr readonly and trying to install the software has no chance to work.
>
> 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.
>
>>     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.
>>
>>> 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.

--     Didier