Adding the base-passwd maintainers to the conversation. TL;DR: this is about the new dh-sysuser wrapper to more easily create system users in package maintainer scripts. I want to see how we can make piuparts happy and cleanup properly after ourselves (by removing the user on purge) and that may involve a registry of UIDs which seems to be maintained in base-passwd now.
On 2016-12-16 23:08:31, Dmitry Bogatov wrote: > control: tag -1 +moreinfo > > [2016-12-15 09:07] Antoine Beaupré <anar...@debian.org> >> >> part text/plain 1199 >> Package: dh-sysuser >> Version: 1.3 >> Severity: wishlist >> >> I think that, under certain circumstances, users should be completely >> removed along with their $HOME directory when the package is purged. > > See #840469 for discussion, why deleting $HOME is troublesome. That would be a great reference to add in the documentation. Something like: .SH LIMITATIONS dh-sysuser does not remove the user on package purge, for security reasons. See bug #840469 for more details. > If you > can propose principled solution -- it would be great. In short: > > - postrm has access only to essential tools I reviewed the thread and that *is* a tricky situation. How about prerm? Can we be wild and remove on purge there? > - What if there is something valuable is in $HOME? What if sysadmin > made some obscure thing, link `ln -sf / $HOME'? In any case, don't follow symlinks. But the nastier attack scenario that was mentionned in #840469 is simply an admin mistakenly or mailiciously setting that user's home to /. The solution here could be to keep track of the *original* home directory so that changing the home directory shouldn't pose problems. I mentionned this in #848240 - having a way of knowing where the homedir will be created would be useful there. Shared UIDs are also a problem, but those can be checked before fairly easily. Could we simply make an exhaustive list of potential problems with rm -rf $HOME and address each one? Or is it an inherently impossible problem? What are admins supposed to do in this case? Review every file in $HOME before they rm -rf the directory? We should be able to automate whatever an admin is expected to do when the user is removed... and if we don't automate it, we should direct admins to do *something*... > - What do to with files outside of of $HOME? Ignore, for now. One could seek and destroy all those files, but that would be too time-consuming. Disk quotas may be (ab)used to figure out if there are remaining files, when enabled, but that's another dependency we probably can't afford. So I would ignore that problem for now. The main issue would be stuff in /var, I believe, so one approach would be to restrict a possible search there. Another would be to have a set of known directories to cleanup on purge that would be specified in the sysuser configuration. > - What about uid sharing? I install torrent client, purge it (files > must stay, you know). Now I install webserver, and it owns my > downloaded files. Wrong. Other operating systems have a static registry of UIDs. For example, FreeBSD ports, when they create users, have to ask for a UID allocation first, by patching two text files as part of their upload: https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/users-and-groups.html This is something we could consider implementing in dh-sysusr. We already have such a voluntary registry in base-passwd: https://sources.debian.net/src/base-passwd/3.5.42/README/ ... on top of the builtin static set of users that are always present, obviously: https://sources.debian.net/src/base-passwd/3.5.42/passwd.master/ Obviously, this would require cross-package coordination, something that is traditionnally more difficult in Debian than in more centralized distributions. But base-passwd seems to be making that effort already, so we could expand on that. Not purging the users only fixes part of this problem, by the way. Since UID allocation is currently order-dependent (e.g. depending on if the torrent client or webserver was installed first, in your example) you may still end up with different UIDs on different machines. While this may not seem to be a problem at first, consider ext-formatted USB drives that travel accross machines or networked filesystems like NFS: in those cases you still have the problem of conflicting UIDs. So a more complete solution to this problem is necessary, and I believe sysuser could be the answer for this. > For now dh-sysuser does not pretend to do something big. You just > create user, optionally with home directory and run some server with > this user. Shell, password, ... are irrelevant. That's a great start! But I'm optimistic and hope we can fix more problems through the use of a standardized tool. :) > I am okay with making it one-stop solution, but I do not know how to > achive it. That's cool, let's talk! ;) A. -- Le matraquage publicitaire est une forme moderne et supérieure de la propagande. - Henri Gobard
