On 18/11/14 18:27, Henrique de Moraes Holschuh wrote:
> Failing to address this would be a severe regression, of the kind that
> introduces a security hole.

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?

I suppose if the default configuration is more permissive than what the
user has configured for a different uid to use, going back to the
default configuration might be a security regression.

> A first option would be a way to load config data from a VAR=VALUE
> text file in systemd units

This already exists (and I think Eric is already using it for something
else), look for EnvironmentFile in systemd.exec(5)...

> and pass some of those vars as the value for User= /
> Group=

... but as far as I know, this is not implemented: the assumption is
that a system service uses a fixed system user, typically either root, a
well-known uid like www-data, or an unprivileged user specifically
created for that service (e.g. "messagebus" for D-Bus).

> 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, and perhaps
also document it as deprecated/discouraged: running minidlna under its
own dedicated uid, and giving it read access to the media it should be
allowed to read (and only those files) via setfacl or whatever, seems
considerably safer than running a network-facing service under the uid
of a "real user" who might also own private documents.

    S


-- 
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/546b95ab.7040...@debian.org

Reply via email to