[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] [pre-GLEP] User and group management via dedicated packages
From:       Jaco Kroon <jaco () uls ! co ! za>
Date:       2019-05-31 7:48:26
Message-ID: 56dc2b2e-d7ff-68d1-bbbe-85c1491f3e5e () uls ! co ! za
[Download RAW message or body]

Hi,

On 2019/05/29 18:01, Michael Orlitzky wrote:
> On 5/29/19 5:50 AM, Jaco Kroon wrote:
>>> This GLEP follows the best practice of leaving obsolete user/groups
>>> accounts intact.  This guarantees that no files with stale ownership are
>>> left (e.g. on unmounted filesystems) and that the same UID/GID is not
>>> reused for another user/group.
>> The type of checks for both this and certain updates contemplated above
>> are similar.  And expensive (resources) as you rightly say. I would
>> provide the tools to perform these checks but in the ebuild I'd rather
>> the checks be done asap (pkg_pretend?).  If we can fail there and
>> stating what the admin should do to rectify the issue that would be the
>> best solution in my personal opinion.  Ie, from the package manager I'd
>> state how, but not actually action these changes.
>>
> My original goal here was to have "emerge -C <user>" actually uninstall
> the user. That turns out to be highly unwise, because you need to audit
> the system for things owned and used by said user, and to clean them all
> up beforehand. That can take forever, and can't be automated.
>
> Plan (b) was to do exactly as you asked: have the uninstall process bail
> out, and tell you what to do. That's... also technically infeasible,
> because we don't have a way to make an ebuild bail out of an uninstall.
> This could change in the future with an EAPI/PMS update, but simply
> isn't an option right now.

I think you misunderstood.  My writing was poor on re-read.

My suggestion is to merely lock the user.  And make sure that the admin 
knows this.  Even locking may need to be configurable but by default I 
would lock.

Further, the tools should be provided outside of the ebuild (baselayout 
perhaps) in order to enable the checks to be completed (ie, confirm no 
files has the user as owner), and then report to the sysadmin how to use 
these tools.

On merge:  Perform the checks before any building starts 
(pkg_pretend/pkg_setup, as per libreoffice example I just looked at).  
Need to recheck again obviously just prior to actually making the 
changes.  Bail early in other words during install.

On unmerge:  Lock user.  Advise sysadmin on how to actually remove the 
user (possibly put it in a database somewhere and check somewhere in 
portage that these users are "linkgering", similar to retained libs that 
gets held because of binaries actually still using it, but never 
automatically removed, just checked if the sysadmin has).  Can't (should 
not) fail.

I hope that clarifies.

Kind Regards,
Jaco


[prev in list] [next in list] [prev in thread] [next in thread]