UNIX permissions to logs folder

written by MattPeterson

It seems that new log files created on UNIX systems (specifically AIX and Linux) are being created with root only permissions. I need to enable other users to have access to read these files. Any suggestions?

I’ve tried issuing a chmod -R, but new files are created with root only permissions.

written by jgstew

You should be able to create a Task that would change the permissions. Have you tried doing this through an action, rather than in the terminal?

written by MattPeterson

The result would be the same if I ran the command from a task for the terminal. The issue is that the new log files are created with the root only permission. chmod only changes the permissions for existing files.

I don’t want to create a task that runs everyday and change the permissions on new files, I’m looking for a better way.

written by jgstew

Sorry, I misread that. I read the “I tried” to mean it wasn’t working, but I get it now… It works, it just is not a good solution to the problem.

What if you change the permissions / owner of the log folder rather than the files themselves. Does that do anything useful when new files are created?

written by MattPeterson

That’s actually what I did. The command I ran was:

chmod 755 -R /var/opt/BESClient/__BESData/__Global/Logs

After running the command all the files have these permissions

-rwxr-xr-x. 1 root root 17412 Apr 2 23:51 20140402.log

-rwxr-xr-x. 1 root root 5844 Apr 3 08:36 20140403.log

If I delete todays log file and restart the besclient service, the new files permissions look like this:

-rwxr-xr-x. 1 root root 17412 Apr 2 23:51 20140402.log

-rw-------. 1 root root 4862 Apr 3 08:50 20140403.log

written by jgstew

Is root the owner of the folder? Does the same thing happen if you use
chown
to change the ownership / group of the folder?

I’m just guessing that new files inherit their permissions from the folder they are created in, but I’m not sure what needs changed.

Otherwise the permissions are being set based upon the BESClient process directly, or based upon it running as root, in which case I don’t think anything can fix it.

written by jgstew

Are the other users that need to examine the logs console operators?

How often do they need to do this?

Could they run an action against the particular client at the time of an issue to collect the logs that way?

written by MattPeterson

Yes root is the owner of the directory.

It seems that the bes client is creating the files with that permission, they are not inheriting from the parent folder. I can’t imaging changing the owner of the directory would make a difference.

I’m trying to enable IEM users the ability to troubleshoot various issues, they would generally have access to the console or an API interface. They will have access to terminal into the UNIX computers as a user, without root access. I could create a task they could run, but I would like to keep things as simple as possible for them and aviod extra steps if I can…

(imported comment written by jgstew)

I’m not sure that changing the group or owner of the parent folder would really do anything, but I think it is worth a try, otherwise I don’t really see a solution other than a task that detects when a new log has root only permissions and changes it. I think the overhead of a policy action like that would be minimal, but definitely not ideal.

written by MattPeterson

Here is what I found will work. I hope this might be helpful to someone in the future…

I can modify the besclient startup file “/etc/rc.d/init.d/besclient” and change the umask from 077 to 022. This will instruct besclient to create new files with the following permissions -rwxr-xr-x. Below is what that section of the file looks like.

limit access to client created files

    umask 077

Then I still need to change access to the Log folder directory to allow others to open it. I can issue chmod to handle that:

chmod -R 755 /var/opt/BESClient/__BESData/__Global/Logs

I can create a task to run this against all my clients once and force it as a policy action.

written by jgstew

Glad to hear you figured it out, definitely sounds like it was a pain to track down.

Can you share your task on bigfix.me ?