suid conflicts from files where sticky bit is set Vs /etc/fstab
I'm working with an Oracle DBA and we are trying to get Oracle Enterprise Manager to work by having sticky bit set on certain files.
There are a number of files that it needs to work with and the sticky bit is set on those files, and yet it still doesn't work. Code:
Code:
remount -o remount /ora/ I'm not sure, because I want to set the sticky bit for various individual files so that the sticky bit is set only on those files Vs opening up for a whole partition and having the chance that there are other files that have the sticky bit set on them and running the risk that someone could do something bad against them. So if someone could explain how the sticky bit works on a partition from /etc/fstab Vs individual files works... thanks |
The fstab doesn't come into it unless the option nosgid is there.
And remounting doesn't do anything either. OEM itself may have some internal checks that will do that. |
Quote:
|
Quote:
In this case though, it wasn't indicated that it was disabled in the fstab. BTW, it isn't called the "sticky bit" - that is a different flag with a different purpose. |
Quote:
So if suid, sgid, and nodev are security flaws, are these being phased out of Linux? |
suid, sgid, and nodev are there to provide security controls. All are used, but should not necessarily be available to general users.
As it stands now, it would be possible to eliminate devices from general filesystems - devices are supported by devtmpfs for most systems. Yet, some embedded will still use an ext[234] for /dev. And that prevents removal. suid is used by administrators to provide access to privileged functions (such as password changing...) so it can't be removed from filesystems used for system binaries.... but that doesn't mean a user should be allowed to give away THEIR account to someone else... Same goes for sgid (used by some services to allow for shared locks, though that usage is fading). |
All times are GMT -5. The time now is 09:55 PM. |