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?

  • 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

  • 1
    #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
  • 1
    @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?

  • 1
    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 clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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