[MXS-310] MaxScale 1.2 does not completely cleanly change to the maxscale user Created: 2015-08-14  Updated: 2015-08-16  Resolved: 2015-08-16

Status: Closed
Project: MariaDB MaxScale
Component/s: Core
Affects Version/s: 1.2.0
Fix Version/s: 1.3.0

Type: Bug Priority: Minor
Reporter: Simon J Mudd Assignee: markus makela
Resolution: Fixed Votes: 0
Labels: None


 Description   

MaxScale 1.2 provides a new option to avoid running as the root user.
However, this does not seem to be executed properly.

In linux I have monitoring scripts which check /proc/<maxscale_pid>/fd/ for the number of descriptors being used. (There was a bug where there was a file descriptor leak some time ago.) and now this fails as the file descriptors and /proc/<maxscale_pid>/fd directory is not owned by maxscale and neither are the descriptor files under /proc/<maxscale_pid>/fd/.

My guess is that the complete process of changing user has not been followed and this needs tidying up so it's probably reasonably straight forward to do. i'll include some information on how to reproduce this in a further comment.



 Comments   
Comment by Simon J Mudd [ 2015-08-14 ]

On CentOS 6 install the maxscale rpm:

# rpm -ivh maxscale-1.2.0-x86_64-rhel6.rpm
warning: maxscale-1.2.0-x86_64-rhel6.rpm: Header V4 RSA/SHA1 Signature, key ID 8167ee24: NOKEY
Preparing...                ########################################### [100%]
   1:maxscale               ########################################### [100%]
#

Start maxscale, just use the existing initial config even if it doesn't really work: that's irrelevant for this.

# /etc/init.d/maxscale start
Starting MaxScale: maxscale (pid 13593) is running...      [  OK  ]
#

Confirm that MaxScale is running and as which user:

# ps auwx | grep maxscale
maxscale 13593  0.2  0.0 889056 47096 ?        Ssl  12:01   0:00 /usr/bin/maxscale --user=maxscale
root     13674  0.0  0.0 103240   892 pts/2    S+   12:02   0:00 grep maxscale
root     27781  0.0  0.0 103244   892 ?        S    09:03   0:00 grep maxscale
#

Now check the /proc/<maxscale_pid> directory ownerships and the fd directory underneath it and its files:

# ls -ld /proc/13593
dr-xr-xr-x 8 maxscale maxscale 0 Aug 14 12:01 /proc/13593
# ls -ld /proc/13593/fd
dr-x------ 2 root root 0 Aug 14 12:02 /proc/13593/fd
# ls -l /proc/13593/fd
total 0
lrwx------ 1 root root 64 Aug 14 12:02 0 -> /dev/pts/2
l-wx------ 1 root root 64 Aug 14 12:02 1 -> /dev/null
lr-x------ 1 root root 64 Aug 14 12:02 10 -> /var/lib/sss/mc/passwd
lrwx------ 1 root root 64 Aug 14 12:02 11 -> socket:[2449756]
lrwx------ 1 root root 64 Aug 14 12:02 12 -> [eventpoll]
lrwx------ 1 root root 64 Aug 14 12:02 13 -> socket:[2449765]
lrwx------ 1 root root 64 Aug 14 12:02 14 -> socket:[2449773]
lrwx------ 1 root root 64 Aug 14 12:02 15 -> socket:[2449774]
l-wx------ 1 root root 64 Aug 14 12:02 2 -> /dev/null
l-wx------ 1 root root 64 Aug 14 12:02 3 -> /var/log/maxscale/error1.log
l-wx------ 1 root root 64 Aug 14 12:02 4 -> /var/log/maxscale/messages1.log
l-wx------ 1 root root 64 Aug 14 12:02 5 -> /dev/shm/maxscale.13593/trace1.log
l-wx------ 1 root root 64 Aug 14 12:02 6 -> /dev/shm/maxscale.13593/debug1.log
lrwx------ 1 root root 64 Aug 14 12:02 7 -> /var/lib/maxscale/data/data13593/aria_log_control
lr-x------ 1 root root 64 Aug 14 12:02 8 -> /var/lib/maxscale/data/data13593
lrwx------ 1 root root 64 Aug 14 12:02 9 -> /var/lib/maxscale/data/data13593/aria_log.00000001
# 

You'll notice the fd directory is owned by root as are the files under it.
They are expected to be owned by the same user as /proc/<maxscale_pid>. You don't configure this yourself explicitly,
but it's usually caused by not following all the steps required in unix/linux to change from one user to another.

So please check that this is done.

Comment by markus makela [ 2015-08-16 ]

The fix to this seems to be to reset the dumpable flag of the process back on after changing the user-id of the process. With this change ownership of all the files under /proc/<pid>/ were changed to the right owner.

Generated at Thu Feb 08 03:58:20 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.