Simon McVittie <s...@debian.org> writes: > I can see the functional regression ("minidlna is running as a totally > unprivileged user now, and can't read my music any more!") but not the > security hole: its default user presumably has as little access as > "nobody", so I don't see how that's insecure?
The scenario I'd be concerned about is if the init script were modified to run the program as a different user that was subject to, say, a SELinux policy. Changing users back might escape additional security measures like that. Another scenario is if the default Debian user conflicted with some user on the local system that was already being used to do something else. In general, I would treat anything involving running daemons as users other than the intended user as a potential security vulnerability unless proven otherwise, given how fundamental user and group are to the entire UNIX security model. >> A second option is to migrate on upgrade the uid/gid information into >> an override in /etc/systemd/system. Requires dealing with a >> dynamically generated config file in preinst/postinst, though, which >> means the tools that help proper config file handling in maintainer >> scripts (ucf, and sometimes dpkg-maintscript-helper) will be of limited >> help. > I think I'd be inclined to do this, as a one-time migration, Yeah, this seems like the right solution to me too. Drop a configuration fragment in /etc/systemd that overrides the user and group and then don't touch it again. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/877fys6wqz....@hope.eyrie.org