Bugzilla – Bug 5035
Prefs migration fails when started as root with --user and --group options
Last modified: 2009-07-31 10:14:22 UTC
My slimserver init script starts slimserver as the root user, but uses --user=max and --group=slimserver. In this configuration, slimserver fails to migrate preferences from 6.5 to 7 format. slimserver changes the specified prefs file to be owned by root:root and creates the new prefs dir as root:root. It then changes to the requested user and group (max:slimserver) and so can no longer write to the prefs file/dir. At this point, the server exits with the following messages in the log: [17:21:27.8835] main::init (360) mDNS startAdvertising... [17:21:27.8872] Slim::Utils::Misc::msg (1147) Warning: [17:21:27.8862] Use of uninitialized value in pattern match (m//) at /usr/share/perl/5.8/File/Spec/Unix.pm line 117. [17:21:27.8887] Path::Class::File::openw (59) Warning: Can't write : No such file or directory at /usr/local/slimserver70/CPAN/Path/Class/File.pm line 59. [17:21:27.8899] Slim::bootstrap::theEND (338) Got to the END I'm starting slimserver as follows: slimserver.pl --daemon --pidfile=/var/run/slimserver/slimserver70.pid --prefsfile=/etc/slimserver/slimserver70.conf --prefsdir=/etc/slimserver/slimserver70 --logdir=/var/log/slimserver70 --logfile=/var/log/slimserver70/slimserver70.log --user=max --group=slimserver --cache=/var/cache/slimserver70 Here's a failed attempt to start: eden:/etc/slimserver# ls -l total 88 -rw-r--r-- 1 max slimserver 30156 2007-05-13 17:21 slimserver70.conf -rw-r--r-- 1 max slimserver 30923 2007-05-11 08:05 slimserver.conf eden:/etc/slimserver# /etc/init.d/slimserver70 start Starting SlimServer music server: slimserver70 [17:27:22.8141] SlimServer OSDetect init... [17:27:22.9394] SlimServer settings init... [17:27:22.9841] Slim::Utils::Prefs::Namespace::migrate (263) failed to migrate prefs for server to version 1 [17:27:23.0475] main::init (257) SlimServer OS Specific init... [17:27:23.0488] main::init (277) SlimServer daemonizing... [17:27:23.0810] Slim::bootstrap::theEND (338) Got to the END eden:/etc/slimserver# pgrep slim 4192 eden:/etc/slimserver# pgrep slim eden:/etc/slimserver# ls -l total 92 drwxr-xr-x 2 root root 4096 2007-05-13 17:27 slimserver70 -rw-r--r-- 1 root root 30156 2007-05-13 17:27 slimserver70.conf -rw-r--r-- 1 max slimserver 30923 2007-05-11 08:05 slimserver.conf Note the ownership before and after. If I remove the --user and --group options then run /etc/init.d/slimserver70 as max, everything works as expected. After having done this, I can then start it as root as normal.
The same thing happens with the new Logs directory if it isn't specified with the --logdir argument. Logs/log.conf is created in the slimserver directory (/usr/local/slimserver in my case), but it is created before the user change so is owned by root and not writable after the user change.
The same is also true for the pid file.
I have since found that various other things don't work properly when starting as root and using --user and --group to change to another user. I'm afraid details are hazy, but one definite situation is that the plugins as par files don't work - assumedly some part of the extraction fails. I would recommend considering whether the --user and --group options should continue to be provided. Are there platforms where an easy workaround is not available? Since noticing that the official Debian startup scripts use start-stop-daemon to change the user before starting, I've modified my init scripts to use this method and all has been well. On other Unix systems, sudo would work equally well. No comment on Windows!
Max - can you still reproduce this issue with the latest packages for Linux?
This is the first I've noticed this bug. I'll be surprised if anything in the new packages will fix this. In fact, I suspect that Max isn't even using a deb package. I've never tried the --user and --group options to slimserver.pl. Note that the RPM uses "deamon --user squeezecenter ..." and the deb package uses "start-stop-daemon --start --chuid squeezecenter ...". I suspect that both of these methods completely switch to the new uid before launching squeezecenter. Max, have you tried changing your init script to do something like "start-stop-daemon --start --chuid max:squeezecenter ..."?
I don't use the Deb packages, unfortunately. I install straight from subversion. See #3 for my workaround using start-stop-daemon. As stated there, I think the best solution is probably just to remove the --user and --group options.
(In reply to comment #6) > See #3 for my workaround using start-stop-daemon. Sorry, I missed that. > As stated > there, I think the best solution is probably just to remove the --user and > --group options. They are certainly not needed for either the RPM or the deb.
This isn't pressing for 7.0. Will investigate post release.
Ross: Can you investigate this one please
Max I could use a helping hand. What edits did you make to /etc/init.d/squeezecenter to set how slimserver starts as root, your user, and your group? I see SLIMUSER, would SLIMGROUP be an acceptable variable?
I was using a custom init script at the time. The current default slimserver script does not use these options. If you want to test this, you'll need to make a custom script that passes --user and --group or just test it on the commandline.
Just to throw another vote to this one. I got hung up installing a nightly because the initial logs in the Logs directory were created and owned by root and when the user transfer took place SqueezeCenter died with an error regarding appender.pm. Changing ownership to the SqueezeCenter user took care of the problem. System Info: SqueezeCenter Version: 7.0.1 - 18632 @ Thu Apr 10 00:27:25 PDT 2008 - solaris - EN - utf8 Server IP address: 192.168.1.3 Perl Version: 5.8.8 i86pc-solaris MySQL Version: 5.0.51a I call SqueezeCenter with the following command: /opt/squeezecenter/slimserver.pl --cachedir=/opt/squeezecenter/cache --user=slimsrv --group=slimsrv --audiodir=/export/home/jroesner/music --pidfile=/opt/squeezecenter/cache/squeezecenter.pid Even using the Service Management Facility I get the same failure unless I start SqueezeCenter as root manually and let the initial logs get created then chown them to the SqueezeCenter user. After that everything works.
It seems to me to be inherently dangerous to only set the effective-uid for SC. The scripted nature of the application, with plugins etc., suggest that both real and effective UIDs should be set to the chosen non-root user, and probably also before opening log-files and pid-file. If it is considered too much effort to fix this then I would propose removing the functionality altogether. Note, this is not a problem for the standard package start-up mechanisms (Debian, Redhat, suse) - see bug 9384 - which use other techniques to ensure that the UID is set appropriately.
Ross, ask the engineers if you still can't get this going to test and see if it's still a problem. If so, Fletch, some of the developers think you might be interested and/or willing to work on this one. Yes? No? :)
It seems like there's probably not enough resources and/or interest to fix this for 7.2.1
Sorry but I still don't know how to do this. Andy pointed me to /etc/init.d/squeezecenter and there is a slimuser pref there, but no group. I'll keep looking into this post 7.2.1
Is it really worth the effort to fix this bug? The RPM and Deb scripts don't need these options, Linux users can solve the problem in other ways, and I doubt that any Windows or Mac users care. Removing the --user and --group options might be the best fix.
I'll let Chris decide. But imho no. Last comment we've seen is from half a year ago, and it's two in total. And it's for migration from 6.x to 7.x+. I'd assume that power users fiddling with special users would have updated already.
I agree with Fletch's comment (#17)
If anyone feels this is important please feel free to re-open and vote. There just doesn't seem to be enough interest.
Reduce number of active targets for SC