File permissions problem installing Under RedHat 9

[Peter Wilson]

Hi all,

I just received my SqueezeBox and after resolving the following issues I think
it is simply the best device I've bought in the last few years, its perfect in
so many ways, I can't imagine life without it and I've only had it three days.

So to the problem I saw installing and using the server software on RedHat 9.

I installed the 5.1.1 software no problem on my machine as root, I didn;t adhere
to best practice when setting this machine up in the first place and I always
log in and use it as root, no other users are defined.

I noted that the server software starts itself up and runs under a newly defined
user it puts in place.

Well.. initially it could not view my music directory, pretty obvious file
permissions problem since the directory belongs to root, a quick chmod fixed
that issue, allowing read permission.

Next I noticed that I could not save playlists, so given my previous fix, I also
added write permissions and that fixed that problem.

Finally I was watching the server software and looking at the number of tracks
it had catalogued (via the information screens on the squeezebox) and I noticed
that consistently as the cataloguing process got to 11600 songs (my full
collection) the server process would crash and once I started the server up
again it would restart the cataloguing process and the cycle would repeat.

Obviously this is another file permissions problem but I could not intuit where
to fix this one... instead looking at the launcher script in /etc/init.d/ there
is an option used to specify the user that the server runs as, initially its
undefined in the script and must default to the slim user, defining the user as
root and restarting the server to run as root fixes this problem.

I just wonder if the install script might in future look for this or similar
situations and prompt the user for permission to fix.

My server has been rock stable and works a treat after that (I get occassional
wireless dropout but not consistently enough to really worry about, I'm tracking
that one)

Peter

[kdf]

Quoting Peter Wilson <Peter.A.Wilson (AT) Sun (DOT) COM>:


> undefined in the script and must default to the slim user, defining the user
> as
> root and restarting the server to run as root fixes this problem.

erk. your choice, of course, but I can't tell you enough just how BAD it can be
to run everything as root.

> I just wonder if the install script might in future look for this or similar
>
> situations and prompt the user for permission to fix.

It woudl be nice if it was possible. I believe there are limits to what the
install script can know ahead of time in order to do this. I recall some
mention of user permissions being handled in it, but it was problematic due to
the limits of an RPM build. I'm sure Victor can clarify that, since the spec
file is mostly his work.

-kdf

[Peter Wilson]

I agree root is bad, I'm not paranoid about security on this machine, it only
exists to serve music to the Squeezebox, nothing else.

But I'd still like to know what the permission problem was that I fixed by
running as root, if anyone has suggestions as to what I can look at to fix the
issue I'm all ears.

Peter

>>undefined in the script and must default to the slim user, defining the user
>>as
>>root and restarting the server to run as root fixes this problem.
>
>
> erk. your choice, of course, but I can't tell you enough just how BAD it can be
> to run everything as root.
>

[kdf]

Quoting Peter Wilson <Peter.A.Wilson (AT) Sun (DOT) COM>:

> I agree root is bad, I'm not paranoid about security on this machine, it only
> exists to serve music to the Squeezebox, nothing else.

hopefully, then, you dont have it connected to teh internet at all or at least
you have closed off every port with the built in firewall. I would be concerned
that the slimserver process itself, which is not designed as any sort of secure
server, could be exploited in some way. It IS, after all, a server listening on
open ports. If you are not connected to the internet with the server PC, you
should consider turning off the "Software Updates" feature in server settings,
additional, behavior. The feature, when enabled, checks the slimdevices website
for any new sofware releases.

>
> But I'd still like to know what the permission problem was that I fixed by
> running as root, if anyone has suggestions as to what I can look at to fix
> the
> issue I'm all ears.

perhaps the slimserver.db file creation. The MP3 Tag Cache feature dumps the
library information to slimserver.db, or .slimserver.db once the scan is
complete. You probably still have a directory that isnt writeable for the
slimserver user. Root would certainly override that.

Playlists also require write permissions, but I think you mentioned dealing with
that already.

-kdf

[Peter Wilson]

Thanks, it did feel like it was crashing due to the inability to write a
summary/database file once it had crawled all over the files in my music
directory, I just didn't know what the file was called, I'll check and see what
I can shuffle to get back to running as the default user.

Something for the weekend.

Security wise, it is as you surmise, isolated from the internet. It sits on a
private wireless network (so that my real wireless G network doesn't get
downgraded, wireless routers are so cheap these days), everything else is
externally connected and secured I only open ports to update the MP3 server when
I need to, but I will fettle the updates setting ... that might cause a hiccup,
I don't think its had time to try to update itself yet.


> perhaps the slimserver.db file creation. The MP3 Tag Cache feature dumps the
> library information to slimserver.db, or .slimserver.db once the scan is
> complete. You probably still have a directory that isnt writeable for the
> slimserver user. Root would certainly override that.

[kdf]

Quoting Peter Wilson <Peter.A.Wilson (AT) Sun (DOT) COM>:


> private wireless network (so that my real wireless G network doesn't get
> downgraded, wireless routers are so cheap these days), everything else is
> externally connected and secured I only open ports to update the MP3 server
> when
> I need to, but I will fettle the updates setting ... that might cause a
> hiccup,
> I don't think its had time to try to update itself yet.

The server will check every time it is started. Being disconnected, your
startup might be delayed while that check waits for timeout.

-kdf