1 |
Hi, |
2 |
|
3 |
On 2019/05/29 18:01, Michael Orlitzky wrote: |
4 |
> On 5/29/19 5:50 AM, Jaco Kroon wrote: |
5 |
>>> This GLEP follows the best practice of leaving obsolete user/groups |
6 |
>>> accounts intact. This guarantees that no files with stale ownership are |
7 |
>>> left (e.g. on unmounted filesystems) and that the same UID/GID is not |
8 |
>>> reused for another user/group. |
9 |
>> The type of checks for both this and certain updates contemplated above |
10 |
>> are similar. And expensive (resources) as you rightly say. I would |
11 |
>> provide the tools to perform these checks but in the ebuild I'd rather |
12 |
>> the checks be done asap (pkg_pretend?). If we can fail there and |
13 |
>> stating what the admin should do to rectify the issue that would be the |
14 |
>> best solution in my personal opinion. Ie, from the package manager I'd |
15 |
>> state how, but not actually action these changes. |
16 |
>> |
17 |
> My original goal here was to have "emerge -C <user>" actually uninstall |
18 |
> the user. That turns out to be highly unwise, because you need to audit |
19 |
> the system for things owned and used by said user, and to clean them all |
20 |
> up beforehand. That can take forever, and can't be automated. |
21 |
> |
22 |
> Plan (b) was to do exactly as you asked: have the uninstall process bail |
23 |
> out, and tell you what to do. That's... also technically infeasible, |
24 |
> because we don't have a way to make an ebuild bail out of an uninstall. |
25 |
> This could change in the future with an EAPI/PMS update, but simply |
26 |
> isn't an option right now. |
27 |
|
28 |
I think you misunderstood. My writing was poor on re-read. |
29 |
|
30 |
My suggestion is to merely lock the user. And make sure that the admin |
31 |
knows this. Even locking may need to be configurable but by default I |
32 |
would lock. |
33 |
|
34 |
Further, the tools should be provided outside of the ebuild (baselayout |
35 |
perhaps) in order to enable the checks to be completed (ie, confirm no |
36 |
files has the user as owner), and then report to the sysadmin how to use |
37 |
these tools. |
38 |
|
39 |
On merge: Perform the checks before any building starts |
40 |
(pkg_pretend/pkg_setup, as per libreoffice example I just looked at). |
41 |
Need to recheck again obviously just prior to actually making the |
42 |
changes. Bail early in other words during install. |
43 |
|
44 |
On unmerge: Lock user. Advise sysadmin on how to actually remove the |
45 |
user (possibly put it in a database somewhere and check somewhere in |
46 |
portage that these users are "linkgering", similar to retained libs that |
47 |
gets held because of binaries actually still using it, but never |
48 |
automatically removed, just checked if the sysadmin has). Can't (should |
49 |
not) fail. |
50 |
|
51 |
I hope that clarifies. |
52 |
|
53 |
Kind Regards, |
54 |
Jaco |