[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Using the user nobody in my package



Thomas Goirand <thomas@goirand.fr> writes:

> Daniel suggested that there was the possibility of setting-up a specific
> user "dtc" that I could setup on my postinst script. But this leads to
> MANY problems that I will explain here. First, there is no way to
> guarantee that the UID will be always the same, and that's the main
> problem.

> 1/ Portability between servers
> If you have many servers using the control panel like we do (we run more
> than 100 servers using it ATM in production), and need to move files
> from one server to another, then the UID wont be the same. It would be
> really anoying to do chown all the time.

Programs that copy files between servers should use the symbolic ownership
rather than the UID/GID values.  I believe that rsync, for instance,
already does this.  The issue here would only be if the servers were
sharing a file system, in which case the administrator is going to need to
create the user on a site-wide basis using a shared user store, such as
LDAP.  If they do that before installing the package, adduser won't create
the user (as I understand it, at least).

> 3/ Changing the defaults for all daemons
> Most daemons we use are running by default using nobody:nogroup, so it
> might be quite complicate to have it use another UID.

This isn't really a technical problem with the approach, just a coding
issue with your package.  I agree that it can be a fair bit of work to
make sure that your package can run as a different user, but it's
certainly possible.  Note that I, for instance, would be very leery of
your package as-is since the whole point of nobody/nogroup is that they
don't own any files and have no access to anything.  As soon as
applications start using those accounts, those accounts are no longer
unprivileged, which defeats their whole point.

> 4/ All daemons have to use the same single UID/GID

The daemon should look up the UID and GID of its user at runtime, and then
this shouldn't be a problem.

> In our system, all hosted files are in /var/www/sites, using a single
> UID/GID. Meaning that with FTP, you can upload files for your web site,
> but as well see the messages for the mail. Also, generated files for all
> the daemons will be done under the UID/GID of Apache, so it can be
> generated by clicking on a button on the interface.

I'm not horribly thrilled by this either, actually, although I know it's a
bit hard to avoid.

> Please post your thoughts here, so we can have a valuable chat on what
> to do.

Well, modifying the Apache configuration in your package to run as a
different user is right out.  I agree that that would be a policy
violation.

Running all of your daemons as the same user that Apache runs as is a
possibility.  I don't really like that as a security model, but it's
certainly better than using nobody/nogroup and modifying Apache to run as
that user as well.

Ideally, I would do something a bit more complex where the Apache code
hands files off to a separate daemon running as a dedicated user for your
package, which then audits what Apache is trying to do and then puts the
files in an appropriate place with the correct ownership.

Hope this was helpful!

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Reply to: