Should sc_serv on linux/BSD run as root?

[mjbrown]

I've long been running the DNAS on BSD as an unprivileged user ('nobody', in fact), via something like this in a startup script:

su -m nobody -c '/usr/local/shoutcast/sc_serv /usr/local/shoutcast/sc_serv.conf'

I also haphazardly set the owner & group on sc_serv file itself, the logs, and directories to nobody:daemon and generally tried to make it so that as little as possible in my shoutcast directory would be exposed to other users on my system. It all ended up being kind of a mess, not really hiding very much because some log would always end up needing to be world-writable. But at least sc_serv was running as someone other than root.

Well now it seems after a system upgrade to FreeBSD 8.2-RELEASE, I've lost the ability to launch sc_serv at all with the existing configuration; I get "logger could not open file ./logs/sc_serv.log". I can start it from the command line when I'm root:

/usr/local/shoutcast/sc_serv /usr/local/shoutcast/sc_serv.conf

...that works OK, but if I try the 'su -m nobody -c' before it, it's no go. I tried setting world read/write on the logs but it still fails with the logger message.

So I'm wondering if there's a recommended way to set up the DNAS on BSD/Linux with security in mind, or if it's just assumed that it's going to be running as root, or what?

[MADxHAWK]

No you should'nt run sc_serv as root. It's always a security risk.

You better should add a user (e.g. Shoutcast) install and run sc_serve as the newly created user.
The errormessage you received most time is a result of wrong access rights. So sc_serve do not have the rights to write to the folder, the logfile is located at or to the logfile.

-MAD

[mjbrown]

Well right, I've always been using the 'nobody' user, who I put in the 'daemon' group, and I had set the logs folder's permissions such that it could write there, and it worked fine until my recent system upgrade. And like I said, even after setting world-write permission on the log files and folder, I still got the error. I will try making another user, but I don't see how the username being 'scuser' or whatever instead of 'nobody' will make a difference. Worth a try though I guess.

[DrO]

it's possible that the upgrade trashed the permissions on the user (shouldn't have happened but is a possibility).

-daz

[mjbrown]

I went ahead and set up a dedicated shoutcast user, but it didn't help. It turns out the problem is that despite the following at the top of sc_serv.conf:

code:
; NOTE: for any relative paths specified are relative to

; sc_serv and not to where the conf file is being stored

...the paths actually are relative to the cwd at the time the server is started. So it works fine if I cd to the parent of the logs directory before running

code:
su -m scuser -c '/usr/local/shoutcast/sc_serv /usr/local/shoutcast/sc_serv.conf >& /dev/null &'

(or whatever), but if I'm somewhere else, say, in /usr/local/rc.d, it says "logger could not open file ./logs/sc_serv.log".

[DrO]

the comment in the example configs is based against running it manually. when running anything via another method, it's always best to ensure that all paths are fully specified. i'll have to remember to remove / amend that message in the example configs at some point.

-daz

[mjbrown]

Even if I run it manually by typing

code:
/usr/local/shoutcast/sc_serv /usr/local/shoutcast/sc_serv.conf

at the command line, I must be in the right directory at the time, or it won't work. The only way it works is if I preface it with 'cd /usr/local/shoutcast && '

[DrO]

if the full path is specified for the config file then it should work as long as any paths in the file are fully qualified - if it's being loaded via an external means then yes it'll act weirdly as it's then likely to be inheriting other options / values in the process. or am i completely missing the point?

-daz

[mjbrown]

The paths in my sc_serv.conf have never been fully qualified, since the comment there says they're relative to sc_serv, they should work as they are:

logfile=./logs/sc_serv.log
etc.

In reality, they seem to be relative to the current working directory, regardless of whether the server is started manually or by some other means. Is that intentional?

[DrO]

it more depends on the platform being used and i've got to go through and validate what actually is happening though i've only ever bothered running the non-windows builds from the folder sc_serv is in instead of doing it elsewhere (and not having paid much attention to that scenario - clearly by my incorrect comment in the examples from when i didn't know the code too well), so will have to amend / remove / validate as time allows.

though really fully qualified paths is what i suggest to be used if there is any doubt.

-daz