Hey. Wouldn't something like the following be a solution:
Apart from some "static" system users/groups which every system has, let system users be in a certain reserved range, which is not the normal 1-1000 range but neither a range where normal users can be created. When packages try to add their system user/group, they check whether it already exists, if it does not or if it's on the reserved range - fine. If it does but is in another range, one must presume that the local admin accidentally used the same name. Package installation should then fail. What we have right now, that many packages simply check whether the group exists and create it only if not, is IMO a security hole. On purge, the user/group shall be removed, but again, only if it's from the reserved range. Existing packages should be mandated to migrate. Maybe it would additionally make sense to come up with some pseudo- reserved namespace for user/group names, too. Like some packages already use debian-<foo> ... or _<foo>. It's not perfect and doesn't guarantee that there are no collisions, but better than nothing. With respect to files owned by some system user/group and wich are left over after package removal... Well, normal removal shouldn't remove the user/group anyway. And on purge, any files "owned" by the package should be properly deleted anyway. If there are nevertheless files which aren't deleted, like e.g. if stuff in /srv/www would be owned by some daemon user/group, one could do the following to provide at least some better protection: When new system users/groups are created, their IDs are recorded and after deleting them these IDs will only be reused, if otherwise the reserved range would be empty (starting with the first one deleted). Cheers, Chris.
