Installation

Should Splunk honor umask when creating files?

_splunkster
Engager

I stood up a clean install of Splunk in AWS using their latest published AMI (currently Splunk Enterprise 8.1.1 running on Amazon Linux 2). This install has a local user named splunk (with a group named splunk) under which the splunkd process is running.

 

$ top -u splunk
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 4613 splunk    20   0  630312 166068  54880 S   0.7  1.0   0:49.25 splunkd
 4766 splunk    20   0  105488  13984   5168 S   0.3  0.1   0:01.60 splunkd
 4795 splunk    20   0 1642752  65616  28848 S   0.3  0.4   0:13.24 mongod
 4874 splunk    20   0 2669968  68704  15300 S   0.0  0.4   0:06.45 python3.7
 5154 splunk    20   0  197692  53536  42432 S   0.0  0.3   0:03.05 splunkd

 

With the instance running, without making any changes, it appears that all new files created by Splunk are getting 600 file permissions. For example, using the web interface under the default admin account and creating a new app-shared dashboard named test results in the following file/permissions:

 

$ ls -al /opt/splunk/etc/apps/search/local/data/ui/views/
total 4
drwx------ 2 splunk splunk 22 Jan 11 18:53 .
drwx------ 3 splunk splunk 19 Jan 11 18:53 ..
-rw------- 1 splunk splunk 46 Jan 11 18:53 test.xml

 

This is not aligned with the umask value of the splunk user. e.g.,

 

$ id
uid=1001(splunk) gid=1001(splunk) groups=1001(splunk)

$ umask
0002

$ cd /opt/splunk/etc/apps/search/local/data/ui/views/

$ touch test2.xml && ls -al
total 4
drwx------ 2 splunk splunk 39 Jan 11 19:23 .
drwx------ 3 splunk splunk 19 Jan 11 18:53 ..
-rw-rw-r-- 1 splunk splunk  0 Jan 11 19:23 test2.xml
-rw------- 1 splunk splunk 46 Jan 11 18:53 test.xml

 

Is this behavior of creating files with owner-restricted permissions (not matching configured umask) expected? If yes (working as expected), is there somewhere in Splunk where these default file permissions can be configured?

Labels (2)
0 Karma
1 Solution

splunker_alan
Splunk Employee
Splunk Employee

The file permissions are set by Splunk Enterprise in order for Splunk to read and write certain files and do no match the umask of the OS. These settings are not adjustable out of the box with the AMI. 

View solution in original post

0 Karma

splunker_alan
Splunk Employee
Splunk Employee

Are you currently logged in as the ec2-user for that AMI? If so, the permission are bit different from the Splunk user. You can change users, stop Splunk, change permission of the directory, and re-launch Splunk.

0 Karma

_splunkster
Engager

The ec2-user is used to access the Linux instance when it is running, but the ec2-user is not used in anyway for the question I'm posing.

My expectation is that the Splunk process(es) should honor the umask of the Linux user account under which they are running. Using this AMI, Splunk's processes are running under a Linux user account named splunk which has a umask of 0002. When Splunk software creates new files, the file permissions are set to 600 which does not align with this umask -- it's as if these file permissions are being controlled through Splunk software, and not by OS configuration.

If you are asking if my touch test2.xml example was done under the ec2-user account, no it was done as the splunk user.

0 Karma

splunker_alan
Splunk Employee
Splunk Employee

The file permissions are set by Splunk Enterprise in order for Splunk to read and write certain files and do no match the umask of the OS. These settings are not adjustable out of the box with the AMI. 

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...