3

I have this problem and would like to see the best practices in the industry.

I am writing a software that uses an open source logging library. One of the features of this library is the ability to create rotating log files. For example, if the max log size is 2GB, then when limit is reached, a new file is created and the old one renamed.

My application has to run as root, because it requires access to lower range port numbers. As a consequence the logs that are being created by the application can only be read by root user.

I would like that the logs be readable by any user and not just by the root user. How can I achieve this? Is there an industry standard to tackle this issue?

Kam
  • 5,878
  • 10
  • 53
  • 97

2 Answers2

2

In a Unix-like operating system, a process's umask controls permissions on newly created files.

Your process has apparently set its umask to 077 (or similar), resulting in group and other not having any permissions. The standard fix would be to use a less restrictive umask, like 022 (group and other can't write but can read and, if appropriate, execute).

Note that changing your umask may have unwanted side effects: if you want files created by your app to only be readable by root, then you'll need to figure out how to set a less restrictive umask when logging and set a more restrictive umask when creating other files. For more information on umasks, see Wikipedia or this question on Ask Ubuntu.

Other, more complicated, solutions to permissions issues are possible. For example:

  • You could start the process with root permissions, bind to low-numbered ports, then drop permissions (assuming you don't need to bind to additional ports after initialization).
  • You should be able to use setfacl to set a default ACL on the log files' directory granting read permissions to whoever you want, in addition to whatever permissions the standard user/group/other bits grant.

But checking your umask is the place to start.

Community
  • 1
  • 1
Josh Kelley
  • 56,064
  • 19
  • 146
  • 246
2

It is possible to give a non-root process specific admin privileges — like the ability to bind to privileged ports. This is far more secure than the all-or-nothing approach of simply running an application as the root user, and is considered a better solution.

In this case, you would want to give it the CAP_NET_BIND_SERVICE capability. This answer is a good starting point for how to do that.

The main two ways to do seem to be

  1. Create a setuid wrapper program which runs as root, and drops all capabilities except the ones you need, and then exec the actual program
  2. Use setcap to set the capabilities of an executable on a single system.

For more information about capabilities, run the following command from a Linux terminal

$ man 7 capabilities

or, visit this site: http://linux.die.net/man/7/capabilities

Community
  • 1
  • 1
jpaugh
  • 6,634
  • 4
  • 38
  • 90
  • The capabilities of files and directories are stored on the system (I think!), so if I copy my binaries to another machine, I would need to re-give the capability to my process on the new machine. Or am I way off? – Kam Jul 27 '15 at 04:07
  • Now, I updated my answer to *actually* have the link I promised! (It's the quintessential link: it shows up in blue and everything!) – jpaugh Jul 27 '15 at 04:43