Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

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 an application which writes a logfile in /var/app/applog.log. This application has to be launched as root, but runs as app:app and can also be demoted to nobody:nobody

What exactly is nobody:nobody and what priviledges does it have?
Is it best to run my app as app:app or nobody:nobody?

The logfile has the same user as the daemon that creates them (app or nobody). But for some reason belongs to the root group.

I have seen that rsyslog uses the syslog user and depending on configuration uses the adm group (I have seen many guides that recommend using this group for rsyslog.What does this group do and is it safe to use it for rsyslog?)
My rsyslog.conf looks like this:

$FileOwner syslog
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$PrivDropToUser syslog
$PrivDropToGroup adm

For rsyslog to be able to read my app's log I have to change the logfile group to adm and for some reason I also have to add rsyslog to adm group (even though I specify adm group in conf) for rsyslog to able to read the file.

Which user:group should the logfiles be and which is the safest way to allow ryslog to read them?

In the end I want my daemon to only be able to write to these logs and rsyslog only be able to read them. No other user should be able to read/modify the logs other than root. Any ideas?

share|improve this question

The nobody user is intended to be exactly that. A generic user account that doesn't belong to anyone and isn't used to run any services. As such, having a file owned by nobody:nobody is a way to make sure that only root has access but is not owned by root.

My rule of thumb would be to create a service account to run your service. That way you have things like httpd running as httpd or apache. That way if there exists a vulnerability in your service then the damage is limited. If, for example, someone can make your website run a local command it will run as a user that can only do stuff in /var/www instead of letting them gain complete control of your system.

Syslog is an interesting one. Typically it doesn't really matter what your syslog server runs as, since it's just listening on a socket and writing out to files. If your application logs using syslog, then everything will just work out. The rsyslog engine, however, can do some more advanced features such as reading a file and then processing it.

In order for rsyslogd to read a file then it must be able to read that file. So in your situation your application's log file needs to:

  • Be world readable
  • Be owner readable by user syslog
  • Be group readable by group adm

Alternatively, you can let rsyslogd remain running at root. That's usually not ideal, but depending on the security posture and compensating controls the risks can be largely mitigated. In either event, some reconfiguration is going to have to happen.

share|improve this answer

From wikipedia:

In many Unix variants, "nobody" is the conventional name of a user account which owns no files, is in no privileged groups, and has no abilities except those which every other user has.

adm: Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole. Historically, /var/log was /usr/adm (and later /var/adm), thus the name of the group. Do not confuse this group with admin, members of the group admin can run programs with root privileges, members of adm are allowed to view some logfiles.

So depending what is in your other logs it should be safe to add that user as it's only read permission.

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.