what sort of file attribute is this: b--Srws-wt

BrianK · 12-16-2004, 07:02 PM

What the heck is up with this file?

I can't seem to find what all the codes mean - I only ever knew about r,w, and x.

Code:

#ll
total 0
b--Srws-wt    1 513757135 animator   0,   0 Jul 16  1973 OPcustom.otl

?!?!

Dark_Helmet · 12-17-2004, 02:07 AM

It looks like that file is really screwed (permission-wise).

The b indicates it's a block device file

The S in the owner's permission block (owner uid 513757135 in this case) indicates the setuid bit is set, but that the corresponding execute permission is not set. In other words, the owner does not have read, write or execute permissions. However, if execute permissions were allowed, then when the file is executed, the process would use the file owner's user id for permission purposes while running. Since this is a device file, executing it doesn't make much sense.

Somewhat similarly, the group permission's s indicated the setgid bit is enabled. That means if the file were executed, the process would inherit the file's group id for permission purposes as well. In this case, the letter is lowercase because the group execute permission is enabled. So the group has read, write, and execute permission. Again, as a device file, it makes no sense to execute the file, but if it were an executable, the program would run with a uid of 513757135 and a gid of animator

For the "other" permissions, the 't' indicates the file has the "sticky bit" enabled. To my understanding, the sticky bit is ignored unless it's applied to a directory. It is lowercase for the same reason the group permission's 's' was lowercase: the execute permission is enabled for all other users.

So, to recap: this file is fubar'd (or whatever person created it is a certified genius/wacko)
block device file
owner (uid 513757135) has no permissions
setuid is enabled
group has all permissions (r,w,x)
setgid is enabled
other users have write and execute permission
sticky bit is enabled (but ignored)

BrianK · 12-17-2004, 04:30 PM

Wow! that's amazing.

Thanks for the reply.

I wonder how this came to be. hmm..

JunctaJuvant · 12-17-2004, 04:59 PM

Did anyone else notice that the uid number 513757135 is almost a palindrome? Coincidence?

btmiller · 12-17-2004, 07:24 PM

Yeah, plus that number's a bit large to be a normal UID. And that major/minor number (0,0 ) is whacked (no device I'm aware of has major number 0). You might try to figure out what created that file -- at leastr it might be worthwhile to fsck the partition its on and check for obvious signs of foul-play.

BrianK · 12-17-2004, 08:30 PM

Quote:

Originally posted by btmiller
Yeah, plus that number's a bit large to be a normal UID. And that major/minor number (0,0 ) is whacked (no device I'm aware of has major number 0). You might try to figure out what created that file -- at leastr it might be worthwhile to fsck the partition its on and check for obvious signs of foul-play.

I know the program that made the file. I don't have any users with that UID (though, I guess that's obvious because if I did, it would show their name).

A while back, I had a RAID array corrupt itself which is probably where the file came from. I'm not sure why this one file made it through (i.e. was readable after the recovery), but that is probably the case. This is the only file that I know of that made it through the corruption without rebuilding the reiser fs on that array.

I just today replaced that horrid controller with a 3ware 9000 series.

frob23 · 12-17-2004, 11:26 PM

From Documentation/devices.txt

The major number 0 is reserved for non-use. It should never be assigned to a device.

Code:

 
0             Unnamed devices (e.g. non-device mounts)
                0 = reserved as null device number
                See block major 144, 145, 146 for expansion areas.