[2016-12-17 11:15] Antoine Beaupré <anar...@debian.org> > > part text/plain 5082 > 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.
Why go all this trouble to just purge system user? While I do appreciate this nit-picking spirit, it is aganist spirit of Debian. After all, leftover system user is just one extra line in /etc/passwd and one more wasted UID, but we have ~32k of them. Also, your proposals require significant complications in dh-sysuser code, which is aganinst my spirit. Practicality beats purity. > 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! ;) -- X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch, Accept-Languages: eo,ru,en | at most once every 24 hours. If matter Accept: text/plain, text/x-diff | is urgent, you have my phone number.
pgpHCvuZF9xNv.pgp
Description: PGP signature
