Linux log file permissions

Linux Log permissions

Put those other users in their own group, make sure the logfiles belong to that group and make them group-readable.

Basically what Manni said, but if you are using log rotate, when new logs are created you will want them to have those permissions too, so look at the create directive of logrotate.

There also might be a group in place for this on your distribution, such as the adm group in Ubuntu.

I prefer using syslog-ng with a specific user and group doing the logging, so that if you want anyone else to be able to view the logs you add them to the «logs» group. You can also use the macro facilities in syslog-ng to rotate logs without using an external program which I find very useful Have a look at this website for some examples http://novosial.org/logging/syslog-ng/index.html I find it very use- and helpful.

syslog-ng is really excellent — it’s far easier to configure than syslog, and has a lot more options. Also, as well as setting default permissions/ownership for logs you can override your defaults at a per log level.

If the need is for the developers, who do not have shell level access on production servers to see relevant application logs, then you can try writing a simple webapp to tail the logs, so that developers can watch the logs on real time.

I have written some simple JSPs in the past to achieve this.

Doing a quick Google takes me to http://sourceforge.net/projects/logtail/ which looks better than what I came up with.

If the need is to access those log files handled by syslog, then you can configure syslogd to write the information that you wish to share to an additional log file and then set group permissions on the file.

For example, if you wish a group of users to view details about errors with the mail service, then you can add a line

mail.err /var/log/shared_mail.err 

And then set permissions for the group to view this file.

Источник

Linux: How to enforce specific permissions on newly created logs which are created by log rotate?

I’ve noticed that the mail logs which are being created in /var/log are being created and owned by root (user and group). I’ve written a Nagios check which monitors the log and in order to allow the Nagios user to access it, I gave the other group read permissions, that is:

Now when I think about it, this is only one log file, when the log file will get filled the log rotate mechanism will rename this file and open a new one, but the new maillog file will not have the read write which I allowed. So my question is, how can I make sure that the log rotate mechanism will create all the new mailllog files with the right permissions for the Nagios user? Thanks in advance

1 Answer 1

logrotate has the create option:

Immediately after rotation (before the postrotate script is run) the log file is created (with the same name as the log file just rotated). mode specifies the mode for the log file in octal (the same as chmod(2)), owner specifies the user name who will own the log file, and group specifies the group the log file will belong to. Any of the log file attributes may be omitted, in which case those attributes for the new file will use the same values as the original log file for the omitted attributes. This option can be disabled using the nocreate option.

More info with man logrotate .

either in /etc/logrotate.conf or a separate file in /etc/logrotate.d and check if no other file already overrides this. How this is configured depends on your OS (e.g. on Ubuntu, this is handled in the rsyslog configuration).

Источник

How to Change Default Permission of /var/log/messages in CentOS/RHEL

By default, /var/log/messages* are created with read-write permissions for ‘root’ user only. There might be a requirement to make the log files world readable for eg to allow an application to read and process the data in it. Changing the permissions on such files using ‘chmod’ might be a temporary solution as they will be recreated with the original permission during the next logrotate cron job. This post will help understand how to set custom permissions (eg 644) on /var/log/messages permanently.

For CentOS/RHEL 4 and 5 (using syslogd)

1. The “create xxxx” directive in /etc/logrotate.d/syslog config file controls the permission of log files managed by syslogd daemon.

2. The example below shows how to change the permission on /var/log/messages to 644 (world readable). Since the intention is to ONLY change permission on a single log file (eg /var/log/messages) we are creating a new config section in /etc/logrotate.d/syslog specifically for changes on /var/log/messages.

# ls -l /var/log/messages -rw-------. 1 root root 424848 June 22 09:18 /var/log/messages

3. First, Remove the /var/log/messages from the main section in the file /etc/logrotate.d/syslog,

# vi /etc/logrotate.d/syslog /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron < ### Remove /var/log/messages from main section sharedscripts postrotate /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true /bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true endscript >

and Create a new section for /var/log/messages as shown below and append it to the same file.

/var/log/messages < ### add /var/log/messages to a sub-section sharedscripts create 0644 ### This directive will change the permission on /var/log/messages* to 644 postrotate /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true /bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true endscript >

Note: syslogd won’t automatically change the permissions on any file that already exists. Copy or move the original file(s) and force an immediate rotation for the changes to take effect.

4. Manually rotate the syslog to see the change in permissions.

# logrotate --force /etc/logrotate.d/syslog

# ls -l /var/log/messages -rw-r--r--. 1 root root 231 June 22 09:19 /var/log/messages

All the subsequent log files will be created with ‘644’ permission.

For CentOS/RHEL 6 and 7 (using rsyslogd version >3)

The $FileCreateMode directive and $umask directive in /etc/rsyslog.conf configuration file allows to specify the creation mode with which rsyslogd creates new files. By default $FileCreateMode directive is compiled in as 0644, which ideally should create files managed by rsyslog with permission 644, but since actual permission depend on rsyslogd’s process umask, all files gets created with 600 permissions. To fix this, edit /etc/rsyslog.conf and add “$umask 0000” right at the beginning of the file that needs modification.

The example below shows how to change the permission on /var/log/messages to 644 (world readable)

1. Check the current permissions of the /va/log/messages file:

# ls -l /var/log/messages -rw-------. 1 root root 424848 June 22 09:18 /var/log/messages

2. Edit the /etc/rsyslog.conf configuration file and the directive “$umask 0000” at the top of the file.

# vi /etc/rsyslog.conf .. $umask 0000 ### Add this to reset the umask# $FileCreateMode 0644 ### This line can be omitted as the compiled in default is already set to 644. Modify this value if you need to set permissions other than 644# *.info;mail.none;authpriv.none;cron.none /var/log/messages $umask 0077 ### Add this to set umask back to default, otherwise all files managed by rsyslogd (/eg /var/log/secure) will be created as world readable (644)

Note: rsyslogd won’t automatically change the permissions on any file that already exists. You would have to delete or move the file and have rsyslogd reloaded for the new permissions to take effect.

3. Lets move the current /var/log/messages file to some other location. This will allow us to create a new messages file with our newly defined permissions.

4. Restart the rsyslog service to generate a new /var/log/messages file.

# service rsyslog restart ### CentOS/RHEL 6 # systemctl restart rsyslog ### CentOS/RHEL 7

5. Check the permission of the file again.

# ls -l /var/log/messages -rw-r--r--. 1 root root 231 June 22 09:19 /var/log/messages

That’s all to it. All the subsequent log files will now be created with ‘644’ permission.

Some more articles you might also be interested in …

Источник

Permission to write to log

I’m working on a Python + Django application and it writes logs. As I run app locally, logged-in as my user, I would like to enable my user to write logs to /var/logs . I tried to add my user to syslog group: sudo usermod -a -G syslog mauro , but it does not works. I wouldn’t like to change path permissions (aka chmod +777 /var/logs ), so, I can use the same set of settings for all environments. Is there another way to do that, than change path permissions?

You don’t need to give the user write access to /var/log . The application itself will write there on its own as long as it’s set to do so in the config.

@NasirRiley but as Iḿ running the app as my user, this is the user that will try write/create files in var/log/*.log .

@MauroBaraldi Why not? That would be a better and safer solution than giving the user full write access to /var/log .

3 Answers 3

Create the log file as root,

sudo touch /var/log/mylogfile.log 

Make it owned by the correct user:

sudo chown user:group /var/log/mylogfile.log 

If you do logfile rotations, make sure that the rotation service ( logrotate or whatever you are using) creates or leaves an empty file with the right ownership whenever the logfile is rotated.

To allow a single user to write multiple logfiles, create a directory /var/log/mylogs that is owned by the user in question, then create the logfiles in that directory.

@Kuslananda this works fine for one file. Is there some solution for user level? As I work with other apps, I would like to enable my user, as a «log writer».

«If you do logfile rotations, make sure that the rotation service (logrotate or whatever you are using) creates or leaves an empty file with the right ownership whenever the logfile is rotated.» Can you elaborate on the correct way to do this?

@FaheemMitha If you rotate the logs as root (as is commonly done), there is no issue with removing or renaming the current log file. However, the service that logs to the file may not have the permissions necessary to create the file in order to write to it, in the case when the service logs directly to the file. If the service uses a syslog facility to do logging, then this should not be an issue.

@Kusalananda Debian uses logrotate . In my case I created a subdirectory for the getmail logs, because that’s what exim does.

@FaheemMitha Yes, creating a subdirectory with the correct permissions and writing the logs there would solve the issue too.

syslogd has permission to write to this directory. It is designed for logging. It will not give any other permissions (just logging). See the linked above for more info (I am not an expert. I only know that it exists, and is what you need).

this is another very nice approach, but it implies in to change log handler. If it is doable, this answer could be satisfactory. And, as the answer you pointed says «If syslogd is running on your box, you can try to use SysLogHandler».

Assuming Unix/Linux environment and it is supporting acl implementation, you can apply an acl like this:

sudo setfacl -m u:mauro:rw /var/logs 

This utility (setfacl) sets Access Control Lists (ACLs) of files and directories, i.e. sets what permission a user(s)/group(s) can have on a particular file or directory.

Refer to man-page of setfacl(1)

Also, setfacl has a recursive option (-R) just like chmod :

You can use capital-x X permission, which means:

execute only if the file is a directory or already has execute permission for some user (X) 

So the new command will be like:

setfacl -R -m u:mauro:rwX /var/logs 

Источник