| 1 |
On 01/28/2017 10:23 PM, Gordon Pettey wrote: |
| 2 |
> |
| 3 |
> That's nonsense for reasons already mentioned by rich0. UIDs don't change |
| 4 |
> except in the case of an admin doing it manually. |
| 5 |
> |
| 6 |
|
| 7 |
It shouldn't be common, but it can and will happen once you put users in |
| 8 |
ebuilds. As an example, imagine an "echo" daemon that listens on a port |
| 9 |
and echoes every line of text sent to it. When building the daemon, you |
| 10 |
compile it --with-uid=<whatever>, and it runs as that restricted user |
| 11 |
with access to nothing. In the ebuild, you depend on sys-user/echo, and |
| 12 |
compile the daemon with the current UID for that user. |
| 13 |
|
| 14 |
Now a year later, someone makes a new revision of sys-user/echo and |
| 15 |
gives it a new fixed UID. Oops, your daemon broke. How do you fix it? |
| 16 |
Rebuild it. You want to rebuild the daemon whenever the UID in the |
| 17 |
sys-user/echo package changes. That's exactly what subslot deps do. |
| 18 |
|
| 19 |
Disregard whether or not it's stupid to do, or whether it will work in |
| 20 |
all cases. *If* a system user *does* change its UID, then you almost |
| 21 |
certainly want to rebuild the packages that depend on it. That can be |
| 22 |
done if everything has a fixed UID determined by a variable in the |
| 23 |
ebuild, and the new user is guaranteed to get that UID. |
Archives