Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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)
Last edited by Dark_Helmet; 12-17-2004 at 02:10 AM.
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.
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.