Bugzilla – Bug 653
must be root to run slimserver
Last modified: 2008-09-15 14:37:04 UTC
I think its silly, and a security risk, to have to be root to run slimserver. In my environment I've checked the latest out of CVS, as user dcohen. So all files have owner dcohen. Then I run using ./slimserver.pl, again as user dcohen. Most things work in this case, but the Templating does not, so if I try to browse the frequently asked questions link (or other links), I am presented only with a blank page. On my console I see a message like: mkdir /home/dcohen//home/dcohen/dev/slim/server/HTML/EN/html/docs: Permission denied at /home/dcohen/dev/slim/server/CPAN/Template/Provider.pm line 860 However when I see this message the directory in question exists. Both HTML/EN/html and HTML/EN/html/doc exist, and both have wrx permission for owner dcohen. So I don't get what's really wrong. dcohen(~/dev/slim/server) > ls -l HTML/EN/html total 88 -rwxr-xr-x 1 dcohen users 71 Sep 15 2003 bar_small_empty.gif -rwxr-xr-x 1 dcohen users 74 Sep 15 2003 bar_small_first.gif -rwxr-xr-x 1 dcohen users 71 Sep 15 2003 bar_small_full.gif -rw-r--r-- 1 dcohen users 4031 Mar 31 2004 controller.html drwxr-xr-x 2 dcohen users 4096 Nov 5 20:30 CVS drwxr-xr-x 4 dcohen users 4096 Nov 5 20:32 docs drwxr-xr-x 3 dcohen users 4096 Nov 3 15:30 errors -rw-r--r-- 1 dcohen users 6631 Sep 10 21:27 help_remote.html -rw-r--r-- 1 dcohen users 7908 Apr 15 2004 help_remote.html.fr drwxr-xr-x 3 dcohen users 4096 Nov 3 15:30 images -rw-r--r-- 1 dcohen users 314 May 14 16:07 lbrsilence.mp3 -rw-r--r-- 1 dcohen users 318 Oct 27 2003 mypage.ico -rw-r--r-- 1 dcohen users 255 Mar 31 2004 remote.html -rw-r--r-- 1 dcohen users 0 Jul 18 2003 setup.html -rw-r--r-- 1 dcohen users 10449 Sep 16 08:35 silence.mp3 -rw-r--r-- 1 dcohen users 1253 Jul 18 2003 silentpacket.mp3 drwxr-xr-x 5 dcohen users 4096 Nov 3 15:30 softsqueeze -rw-r--r-- 1 dcohen users 110 Mar 31 2004 test.html drwxr-xr-x 3 dcohen users 4096 Nov 3 15:30 Volume when I run with sudo slimserver.pl, the templating works fine. But again its unfortunate that I have to run slimserver, and I assume everything it launches, as root. Ugh.
I think this is a problem trying to write the TT cache. I have similar messages after checking out as fishbone, running as user fishbone...then trying to run the server as user slimserver, I get messages regarding the cache. my prefs file has: cachedir = /usr/local/slimserver/Cache I wonder if, in your case, cachedir=/usr/dcohen, or its blank and ~ is the default cachedir.
Created attachment 199 [details] dose this help? I'm wondering if there is a problem with the double slash. maybe a default without a trailing slash would let it work properly? best not to just openly cache files in a user home dir anyway, since other things also end up in the cachedir.
Ah... its good to understand the reason. At some point in the past I ran as root. And these cache files were created and owned by root. I deleted the cache directory and now when I run as dcohen it works OK. This is good. Whats not so good is where the cache files are. Here's the directory, which as you can see looks like some kind of mistake... /home/dcohen/home/dcohen/dev/slim/server/HTML I.e, the /home/dcohen/home/dcohen part. My pref file says: cachedir = /home/dcohen
The issue is that for the default install on non RPM,Mac or Windows, the cachdir is set to ~. The right thing to do is to create and specify a cachedir: mkdir /home/me/.slimservercache ./slimserver --cachedir=/home/me/slimservercache/ Patches welcome.
maybe a patch isn't the right thing for this. if we're talking about tar.gz or cvs installs only, this is probably better handled as part of the README. mkdir isn't the best thing to run from slimserver.pl. the cvs instructions on teh website coudl add the note about creating a cachedir, or a README included in the cvs and tar.gz might take care of this as well.
I"ve got no problem with slimserver doing a mkdir in the $Bin directory to hold the caches, as it's already making lots of dirs for the caches themselves.
This hasn't been a problem for me in quite some time. Dean, unless you know something I don't, go ahead and resolve.
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006. I am setting them to targets of 6.2.1 to keep them from showing up in my queries.