NSLU2/Firefly setup problems

[rpedde]

@andyg wrote:

I assume that last line should be

find mp3 -type f exec chmod 664 {} ;

rather than -type d as per what you write further on…

thanks again, andy

Ah, exactly. Good catch.

The rest aren’t strictly necessary, if the permissions are already okay. I’d guess they will continue to be fine as you add new files.

— Ron

[Anonymous]

As far as permissions, I’d do something like this from the /share/flash/data directory:

chown -R admin:everyone mp3
find mp3 -type d exec chmod 2775 {} ;
find mp3 -type f exec chmod 664 {} ;

I tried this and got the following back:

# cd /share/flash/data

# chown -R admin:everyone mp3

find mp3 -type d exec chmod 2775 {} ;

# find mp3 -type d exec chmod 2775 {} ;

find: paths must precede expression

Usage: find [path...] [expression]

# 

… so not sure what’s missing here, but I’m not too worried – I can now dump files into the /mp3/iTunes Music folder so at least I’m back in business in that respect…

[sansp00]

Would it be more:
find mp3 -type d -exec chmod 2775 {} ;

than …
find mp3 -type d exec chmod 2775 {} ;

There is the minus in front of the exec AFAIK.
Patrick S.

[Anonymous]

Would it be more:
find mp3 -type d -exec chmod 2775 {} ;

than …
find mp3 -type d exec chmod 2775 {} ;

There is the minus in front of the exec AFAIK.

spot on Patrick, that’s done it. Here’s a snippet for anyone following this thread:

# cd /share/flash/data

# ls -l

drwxrwxr-x    3 admin    everyone     4096 Aug  1 18:17 TV

drwxrwxr-x    5 admin    everyone     4096 Jun  9 09:12 backups

drwxrwxr-x    3 admin    everyone     4096 May 24 22:59 dropfolder

drwx

2 root     root        16384 May 10 18:54 lost+found

drwxrwxrwx    5 admin    everyone     4096 Aug  1 19:12 mp3

drwxrwxrwx    2 root     root         4096 Aug  2 21:38 mt-daapd

drwxrwxr-x    3 admin    everyone     4096 May 22 21:54 public

-rw

1 root     root        64064 Aug  2 18:20 quota.user

-rw

1 root     root        64064 Aug  2 18:19 quota.user~

# find mp3 -type d -exec chmod 2775 {} ;

# find mp3 -type f -exec chmod 664 {} ;

# cd mp3

# ls -l

drwxrwsr-x    2 admin    everyone     4096 Jul 28 10:02 Desktop Folder

drwxrwsr-x  589 admin    everyone    20480 Aug  2 08:22 iTunes Music

-rw-rw-r--    1 admin    everyone  7415729 May 14 21:27 iTunes Music Library.xml

# cd "iTunes Music"

# ls -l

drwxrwsr-x    3 admin    everyone     4096 Aug 12  2003 1 Giant Leap

drwxrwsr-x    3 admin    everyone     4096 Aug 20  2003 A Man Called Adam

drwxrwsr-x    3 admin    everyone     4096 May 12  2004 AURA

drwxrwsr-x    3 admin    everyone     4096 Aug 12  2003 Aaron Neville

drwxrwsr-x    3 admin    everyone     4096 Jan  3  2004 Adama Yalomba

drwxrwsr-x    3 admin    everyone     4096 Jan  3  2004 Afel Bocoum

drwxrwsr-x    3 admin    everyone     4096 Jan  3  2004 Aicha Bint Chighaly

drwxrwsr-x    3 admin    everyone     4096 Apr 11  2004 Aim Feat. Kate Rogers

drwxrwsr-x    3 admin    everyone     4096 Aug 20  2003 Airlock

drwxrwsr-x    3 admin    everyone     4096 Apr 12 20:24 Al Di Meola _ John McLaughlin

drwxrwsr-x    3 admin    everyone     4096 Apr 12 20:25 Al DiMeola

drwxrwsr-x    3 admin    everyone     4096 Apr 10  2004 Albert Collins

drwxrwsr-x    3 admin    everyone     4096 Apr 10  2004 Albert King

drwxrwsr-x    3 admin    everyone     4096 Sep 27  2003 Alex Konadu

drwxrwsr-x    6 admin    everyone     4096 Dec 30  2004 Ali Farka Toure

drwxrwsr-x    3 admin    everyone     4096 Aug  1  2005 Ali Farka Touré And Toumani Diabeté

without wanting to lean on anyone for a linux tutorial ( 😯 ) I guess the only thing that I’m not completely understanding is the 2 numeric in front of the 775 which has introduced the ‘s’ at the end of ‘group’. I have read up sufficiently on the permissions process but I haven’t seen this format before. Ron, Partick or anyone else inclined… care to elaborate? 😉

[sansp00]

Sure, having work on Unix system for the past 10 years, I got to know my way around a bit (even if I am just a programmer, not a tech …)
The permission go as this:
digit 1:user who owns
digit 2:user in the group
digit 3:other user not in the group
digit 4:all user

Patrick S.

[rpedde]

@sansp00 wrote:

Sure, having work on Unix system for the past 10 years, I got to know my way around a bit (even if I am just a programmer, not a tech …)
The permission go as this:
digit 1:user who owns
digit 2:user in the group
digit 3:other user not in the group
digit 4:all user

Patrick S.

Mostly, but the first digit has to do with suid/sgid. The ones you see in ls are the last three digits.

The permission blocks are made of three sections. One for owner, one for members of the owning group, and the other for everyone.

So when you see permissions on a file like:

rw-rw-r–

That means the owner of the file has read/write permissions. Anyone who is a member of the group that owns the file has read/write permissions. Everyone else has read permissions. Makes sense, ya?

Okay. If you wanted to, you could think of those permissions a a list of permissions that are flagged as off or on. In the case above, you could think of the permissions as toggles, right? Like, you could think of the permission from left to right as “on, on, off, on, on, off, on, off, off”. You could represent that more simply with a 1 or 0 for on or off:

110110100

When it’s written like that, there is a easy-to-see typographical isomorphism between that and rw-rw-r–. Cool. So what?

Well, the obvious thing to do (for cs people, anyway 🙂 is to represent those as numbers rather than binary digits. The numbers break apart logically in groups of three, so it makes sense (again, from a cs standpoint) to group them numerically as one digit per group of three. (if you were bored, or a math geek, you would see that it means that the maximum digit range would be 0-7, or would mean that this was a base-8 number system. Octal! Neat!)

So breaking into groups of three, you have:

110 110 100

Or, translating from binary to decimal:

664

Which is a lot more concise. If you spend a second playing with the numbers, you’ll see what the individual digits are:

7 is read/write/execute
6 is read/write
5 is read/execute (you pretty much have to have r to x)
4 is read only
3 is write/execute (which doesn’t make sense, and you won’t see it)
2 is write only (which again, doesn’t make much sense, and you wont’ see it)
1 is execute only (which you don’t generally see either)

Good so far?

Up to here, you’ve probably already figured out. There are a couple things worth noting at this point that you probably haven’t seen or figured out yet. These points are:

1. There is no “delete” permission. Instead, that’s controlled by write permission on the parent directory. So if the directory is 775, and the file is 666, (and I’m not the owner or a member of the owning group), then I can’t delete the file. I can overwrite or truncate the file, though, as I have write permissions to it.

2. The x permission is execute for files, but on directories, it means to allow traversal. So again, if I’m a “everyone else” user, and a directory is 774, implying I have read permission to the folder, it won’t matter, because I can’t cd to it. I can’t see what is in the directory because I don’t have permissions to traverse the directory. No x. So a directory that is 444, which would seem to imply world readable actually isn’t. That’s why you see 7s and 5s in directory permissions. Along with the r, you *have* to have x. Not sure why, that’s just how it is.

Okay. that’s the last three, and the first digit is the most confusing. That deals with setuid, setgid and the sticky bit.

Files (and directories) can be flagged as setuid, setgid, or sticky. Those bits can be represented in octal just like the permissions, as flags for setuid, setgid, and sticky.

010, for example means setuid off, setgid on, sticky off.

That’s the first number in chmod. So “chmod 2775” means:

set permissions to rwxrwxr-x, and make the folder setgid.

Great. So what do those bits do?

Sticky is the easiest. On executables, it means don’t flush the application pages when the program exits. Keep them pinned in memory. In old systems that were starved for memory, and there were particular programs that were run nearly continuously, it might make sense to keep a program completely in memory to reduce startup thrashing when the program started. Nobody uses this anymore, as disk speeds are higher, memory paging is cheaper, and we aren’t in 1985 anymore.

The sticky bit on folders, though, is still useful. It means that only the owner can delete or rename files. So, for example, on the /tmp directory, you might want to allow everyone to read and write in the folder, but don’t want somebody deleting anyone elses temp files. You could do that (and frequently you’ll see your system *does* do this) by setting the stick bit on the /tmp directory:

chmod 1777 /tmp

Without the sticky bit, anyone could delete anything in there, even if it wasn’t their file.

Okay. So now setgid and setuid.

setuid is the easiest, so let’s look at that. One frequent problem early on in unix was having programs that needed access to the system, but users didn’t have permissions to access those features. Think of a cd burning program. Users generally don’t have write access to physical disks, so things like cd burning programs wouldn’t work for them. It would work for root, since root has access to it, but there needed to be a way for users to run a program as a user with more permissions. That’s what setuid does for executables. If you have a file that’s owned by root, and the setuid bit is set, then whenever the program is run (by anyone that has permissions to run the program), then the program gets run as the root user.

Make sense? In the case of the cd burner, if the program was owned by root and setuid, then anyone that ran the program would run it as root, and then they would have the permissions to access the devices they need to.

Sadly, it also means that people can exploit the program to do various damage, so setuid root programs are few and far between, but still, that’s the original intention. Well, not entirely few and far between: http://www.securityfocus.com/bid/24953/info

Still, if you look around your system, you might find some simple programs that are setuid. traceroute and ping for example.

Some systems interpret the suid bit on directories to mean that any files saved in the directory should be owned by the user that owns the parent directory.

As far as sgid goes, that’s the middle bit. That’s like the suid bit, except for the group. That doesn’t make much sense in the case of executables, but for directories it does. When the sgid bit is set, then any file saved in a folder is owned by the group that owns the folder.

That’s handy. If you have multiple users adding files to the same directory and they belong to multiple groups, it’s possible they could save files in a folder that belong to a group that others don’t have. So files that one user makes in a shared folder could end up being non-writeable by other users that have read/write permissions in the folder:

So sgid on a folder makes sure that the group membership is preserved, making sure that future additions to the folder maintain the same permissions as the files already in there.

Okay, this is already turning into a tutorial, so I’m going to close this out, but that’s what the first octal digit is. setuid, setgid, and sticky bit.

[sansp00]

Ron, you should start writting man pages 😉 I’ve never seen such a clear and detail explanation of this anywhere !
Patrick S.

[Anonymous]

without wanting to lean on anyone for a linux tutorial

Thanks Ron – that’s most definitely a tutorial… 😆 and a lot more precise than the books!

I’ll leave you alone now! 😉

[Author]

Posts