View Full Version : cannot get access to /home/myname/mp3 --RESOLVED!

Kevin Davison
2004-04-12, 20:52
Looks like I found the problem. Slimserver wasn't running as root. I tried
typing "./slimserver.pl --user root --daemon" and it now takes my music
directory. Go figure. I still am clueless why it didn't take the directory
when the directory was owned and group owned by Slimserver, but it likes
running as root so I'll keep it at that, unless there is a security
vulnerability there that someone knows of. Thanks for all your suggestions!


-----Original Message-----
From: S. Ben Melhuish [mailto:sben (AT) pile (DOT) org]
Sent: Monday, April 12, 2004 8:53 PM
To: Kevin Davison
Subject: [slim] cannot get access to /home/myname/mp3

On Apr 12, 2004, at 4:17 PM, Kevin Davison wrote:

> I get: drwxr-xr-x 143 kevin mp3 4096 Apr 11 18:27 /home/kevin/mp3
> Does this mean anything to you? ^^^

By the way, I don't know how comfortable you are with Unix security,
but I didn't see a response to this part of the message, so here's the
quick Unix security tutorial:

drwxr-xr-x 143 kevin mp3 4096 Apr 11 18:27 /home/kevin/mp3
1(2)(3)(4) (5) (6) (7) (8 ) ( 9 ) ( 10 )

1: This indicates that you're looking at a directory.
2: This indicates that the owner (see 6) has read, write, and execute
permissions. (I think directories need to have execute permissions if
you want someone to read them, but I'm not sure about this part, I just
treat it as voodoo.)
3: This indicates that the group (see 7) has read and execute
4: This indicates that everyone else has read and execute permissions.
5: I have no idea what this is.
6: The user 'kevin' is the owner.
7: 'mp3' is the group.
8: This directory entry takes up 4KB. (The *contents* of the
directory may be much larger, but all the bookkeeping about what the
directory contains, etc., take up 4096 bytes.)
9: This directory was last modified at this time. (Probably when you
last added a file or changed ownership.)
10: This is the full path to the directory.

2 and 6, together, imply that 'kevin' has full access to the directory.

3, 4, and 7, together, imply that everyone else has read-only access to
the directory.

Security doesn't "inherit", so subdirectories can have entirely
different permissions. You can use the -R (I think) flag on chown and
chmod (the commands which change ownership and permissions,
respectively) to recursively change the directory and all its contents.

As someone suggested, the slimserver wants write permissions, and
doesn't seem to have them.

As far as the chmod command that someone else suggested: Each
permission has a number associated with it; r is 1, w is 2, x is 4.
`chmod 777 [filename]` changes the permissions to "everyone has
read/write/execute access". The directory you listed above has 755
permissions, which is more normal. 775 would be 'kevin' and 'mp3' have
full rights, everyone else has read-only, which is probably close to
what you want for the slimserver.

Hope that helps.

-- S. Ben Melhuish

Pat Farrell
2004-04-12, 21:02
At 11:52 PM 4/12/2004, you wrote:
>Looks like I found the problem. Slimserver wasn't running as root. I tried
>typing "./slimserver.pl --user root --daemon" and it now takes my music

Glad you got it working.
This is not a great solution, as you point out...

>running as root so I'll keep it at that, unless there is a security
>vulnerability there that someone knows of.

There is no known security vulnerability, but that doesn't change
that it is a bad idea to run as root when you don't need to.
And the slimserver is designed to run as user "slimserver"
with is much less powerful than root.

Perhaps your system didn't have that account setup correctly?

As a long term solution, you really should figure out how to not
need root privs, it is just bad form. It is literally impossible to
know if a program is safe or not. It is much better to assume
that is it not, and be safe, not sorry. Not that any of the slimserver
developers are ever going to be bad, but they are human,
and bugs happen.