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

I have some non-privileged "role accounts" that need the ability to view [some of] the local syslogs (eg. /var/log/messages) for debugging purposes.

This is explicitly local log data, not remote syslog, logstash, etc. Obviously, there's several ways to address this issue. What I'd like to know is if there is a fairly "standardized" way to solve this issue.

Typically, I solve this problem with sudo but either POSIX groups or acls is attractive as it's few chars for the users to type and it removes entries from the sudo log. However, I don't believe I've ever seen that done before. What is your experience? How do large install base sites address this?

share|improve this question
Also worth noting is that I find fiddling with the syslog default umask undesirable as it would expose the secure log/etc. – Joshua Hoblitt Sep 12 '12 at 19:11

You could consider configuring your syslog deamon (e.g. rsyslog) to mirror the output to another file on a location of your choice. Then make use of regular filesystem permissions. hint #1

Alternatively, one can set up remote logging for some servers and only provide access on a separate machine for the users reading log output. This can be useful for developers not having access at all on production servers but sysadmins want to provide developers log output directly. hint #2

share|improve this answer
#1 moves the permissions issues to another file but doesn't address access control. I assume this is a fairly common issue and it seems like there should be a fairly "industry standard" way of addressing it. #2 is explicitly outside the scope of the question. – Joshua Hoblitt Sep 12 '12 at 20:04
@JoshuaHoblitt The "industry standard" way is to use groups or acls. – Michael Hampton Sep 12 '12 at 22:02

Typically, I solve this problem with sudo

erk. This also implies that you create a shell script to run a program to access the file - which means that users are restricted to using whatever program(s) you specify.

Why not just create a Unix group which is allowed read access, change the group ownership of the file and amend the relevant logrotate job to recreate these permissions?

share|improve this answer
No particular reason not to do that. I'm just surprised that I haven't encountered this on systems not provisioned by me. Thus this question... – Joshua Hoblitt Sep 13 '12 at 16:39
@symcbean: why change the ownership if you can use ACLs? Unix file permissions are very limiting. – 0xC0000022L Mar 16 '15 at 12:20
@0xC0000022L: because its easy to prove that Unix permissions are correct. It's really hard to audit ACLs, and I've seen many ACL configurations where (a deep, manual examination has revealled) there are gaping security holes. And coincidentlally there are also performance issues on some filesystems and issues with backup software support. – symcbean Mar 16 '15 at 16:49

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.