My application requires read access to /var/log/messages, which belongs to user and group root. What is the minimal exposure level required on /var/log/messages so my application can read it?

Presently, my plan is to change the group ownership of /var/log/messages to a new group, and add root and my application user to it, but this would also give the application write privileges to /var/log/messages.

OS: Centos 5.5


No need to add root to the group as it will have access via the user privs anyways, just give group read to what ever group you decide. Remember to make the changes with logrotate as well or the group changes will get wiped nightly.

  • Where are the logrotate scripts located?
    – gAMBOOKa
    Apr 12 '11 at 16:08
  • 2
    /etc/logrotate.d/ is the folder for the broken out logrotate scripts. /var/log/messages is in /etc/logrotate.d/syslog. You would need to move /var/log/messages to it's own file inside /etc/logrotate.conf and then using something like 'create 0640 root new_group' tell it to create the file properly.
    – rfelsburg
    Apr 12 '11 at 16:10
  • You would need to move /var/log/messages to it's own file inside /etc/logrotate.d/
    – Massimo
    Sep 29 '18 at 9:53

Just to expand a little on the above answers here is a real world use case. I run the enterprise log analysis application Splunk on a Redhat box. It runs under the splunk user and splunk group. This prevents splunk accessing the logs in /var/log as they are only accessible by root (or a sudo admin)

In order to allow read only access for splunk only I've used some ACL's and modified logrotate to persist it.

You can manually set the ACL with

sudo setfacl -m g:splunk:rx /var/log/messages

This will not persist as logrotate will not re-apply the ACL setting so for a more permanent solution I added a rule to logrotate to reset the ACL. I added the file..



        /usr/bin/setfacl -m g:splunk:rx /var/log/cron
        /usr/bin/setfacl -m g:splunk:rx /var/log/maillog
        /usr/bin/setfacl -m g:splunk:rx /var/log/messages
        /usr/bin/setfacl -m g:splunk:rx /var/log/secure
        /usr/bin/setfacl -m g:splunk:rx /var/log/spooler

Check the ACL status of a file with

$ getfacl /var/log/messages

For more info on ACL's see https://help.ubuntu.com/community/FilePermissionsACLs http://bencane.com/2012/05/27/acl-using-access-control-lists-on-linux/

  • also posted to splunk answers answers.splunk.com/answers/4253/…
    – nick fox
    Jun 1 '16 at 9:55
  • 2
    Note that splunk doesn't require execute permission on log files, just read.
    – rojs
    Apr 13 '17 at 19:44
  • 1
    @nickfox Is that the entire content of /etc/logrotate.d/Splunk_ACLs that you've posted there? You don't actually need to specify any paths for logrotate to process the postrotate bit? Sep 13 '17 at 20:51
  • hmmm Don't think so. I didn't want to modify the existing logrotate configs for system logs and I also didn't want to replace them with my own. This way the custom modification for splunk exists independently. Allowing you to deploy with a package or puppet etc. thats what /app.d/ directories are for. Of course I could be wrong, it was over a year ago since I did that
    – nick fox
    Sep 15 '17 at 9:12
  • 1
    Just a note suggesting that if you use the X option (as in capital X rather than x) it will add execute only if the file is a directory or already has execute permission for some user
    – steoleary
    Mar 6 '19 at 13:21

Your plan is acceptable and in the "traditional" Unix permissions scheme is the best way to go.
Another option is to have syslog divert the messages of interest to another file (which avoids giving the app user access to anything sensitive that may be in /var/log/messages).

If you don't feel like being bound by the traditional permissions scheme of User/Group/Other you can also use POSIX ACLs (other, possibly better howtos/info available via Google) to give your app user read-only access to /var/log/messages -- this is a bit more fine-grained and doesn't risk accidentally putting someone else in the application's group and giving them access to things they shouldn't be able to see.


Yip I've used setfacl to do this to give access to the mail.log file for a customer, not you will also need to stick a command in the logrotate.conf file to re-set the ACL after the logs have been rotated eg:

         /usr/bin/setfacl -m o::r /var/log/mail.log  

Note I've only just set this up, and have not tested, but though it would post back here, can.t see why it wouldn.t work, someone correct me if I'm wrong.


You can use ACL for this. It allows you to set specific additional access rules for specific users and files.


I would check "perm" option for syslog-ng, if that is the logging software you are running. Ref: https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.16/administration-guide/12


Else you could add additional log file like /var/log/apps/app1_messages.log


once you configured your ACL as other people said, instead of put all your acl rules in the postrotate configuration, you can swith logrotate to use copytruncate instead of creating a new log file each time

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.