Thomas Goirand <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
