Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

for a reason I do not really understand, everyone wants sudo for all and everything. At work we even have as many entries as there are way to read a logfile (head/tail/cat/more, ...).

I think, sudo is defeating here.

I'd rather use a mix of setgid/setuid directories and add ACL here and there but I really need to know what are the best practices before starting up.

Our servers have %admin, %production, %dba, %users -i.e many groups and many users. Each service (mysql, apache, ...) has its own way to install privileges but members of the %production group must be able to consult configuration file or even log files. There is still the solution to add them into the right groups (mysql...) and set the good permission. But I do not want to usermod all users, I do not want to modify standards permissions since it could change after each upgrade.

On the other hand, setting acls and/or mixing setuid/setgid on directories is something I could easily do without "defacing" the standard distribution.

What do you think about this ?

Taking the mysql example, that would look like this:

setfacl d:g:production:rx,d:other::---,g:production:rx,other::--- /var/log/mysql /etc/mysql

Do you think this is good practise or should I definetely usermod -G mysql and play with standard permissions system ?

Thank you

share|improve this question

Best practices: maintain the sudoers file and use sudo.

On my personal machine, I prefer setuid/gid, but I'm the only one on my computer; and I don't do it to anything blatantly dangerous like rm.

share|improve this answer
+1 - I've seen ACL's trip up many people as they are not expected/common - and will your logrotate tools preserve ACLs? Just use sudo - it's easier for the next guy to understand. – James Jun 1 '10 at 21:48
with default acl set, logrotate wouldn't hurt at all here. – Xavier Maillard Jun 1 '10 at 23:14
Another thing: do your backups support ACLs? Better make sure... – Mei Jun 20 '10 at 1:30

Best practices (and most common) tend toward using sudo. Sudo offers you fine-grained control, and the configuration can handle multiple machines all at once.

Using ACLs can complement this - sudo handles operations as root; ACLs give and take away rights to directories and files to users and groups. I wouldn't count on setgid and setuid to do anything reasonable.

I would also implement the wheel group; this will help increase security. Check to see if your su program supports the wheel group.

One more thing: if you have view or less as a way to read a logfile, then you are at risk: both of these programs offer shell access.

share|improve this answer
But the shell access can be disabled in sudoers using restrict or noexec. – Dennis Williamson Jun 1 '10 at 21:58
I do not see why setuid/setgid (as mysql here) would be more dangerous than using sudo. Having root setuid is different story but here we are talking of some unprivileged users. – Xavier Maillard Jun 1 '10 at 23:13
Restricting shell access by using sudo to block /bin/sh can be subverted trivially. If /bin/sh is restricted, use /bin/ksh. If /bin/ksh and /bin/sh are restricted, copy /bin/sh to /tmp/sh and use that. If /sh is restricted, name it /tmp/mysh. And so on. Also... Xavier is right. – Mei Jun 20 '10 at 1:34

It seems to me that the sudoers option is a bit more compact than the setuid/setguid/ACL.

Without grouping users, your ACLS will be very long. And if you do group users, you're back to the same place you started.

The bigger issue is that without some kind of central management of it, access control gets spread throughout the filesystem. Of course you can easily get around that with i.e. macros, templating, config management and so on. But that's a whole other layer which does nothing to reduce complexity.

In my small Drupal shop I use ACLs quite extensively for all working files but sudo for all management access. The configuration management layer I'm using is Ansible and the nice thing about that is that I can easily template users, their roles, and therefore what groups they get, on what machines, and so on. Sudoers is similarly managed. That seems pretty best practice to me because it is most transparent.

Of course, I probably don't have near as many users or groups as you. I could envision putting ACLs in config management as well. But for the life of me, I don't see a straightforward way of managing many machines, many users, and many groups that way.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.