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.


Looking around online, we noticed that removing nosuid for a directory under /etc/fstab and running

Fixed the issue and now OEM works ok.

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.

Then why have nosuid set there at fstab if it doesn't come into play?

It is up to the administrator. setgid is considered a security weakness. For me, any filesystem that can be written to by a user should have several things disabled - setuid, setgid, nodev... Even if a file manages to get the flags set... they don't work.

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.

Yes, your right. Thanks for correcting me.

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).