Re: NMO not setuid-root (Unix-only)

Jonathan Leffler <jleffler_at_earthlink.net> wrote in message news:<fSTqd.3806$u81.2606_at_newsread3.news.pas.earthlink.net>...
> Yong Huang wrote:
> > wizofoz2k_at_yahoo.com.au (Noons) wrote:
> >>"Howard J. Rogers" <hjr_at_dizwell.com> wrote:
> >>>>RemoteOperationException: ERROR: NMO not setuid-root (Unix-only)
> >>>>
> >>>>Any suggestions? [...]
> >>
> >>Someone forgot the good old chmod 4777 on executable "oracle"?
> >
> > I think it's chmod 6751. If it were 4777, the executable could be
> > overwritten by anyone, and removed if the directory it is in allows
> > anyone to change.
>
> In general, a file can be removed if the directory it is in allows you
> to write in the directory, regardless of the file's permissions. If
> you have a directory with the sticky-bit set (eg /tmp - usually 1777
> permission), then you can only remove the file if you own the file, or
> if you own the directory, or if you're root*.
>
> But you're right - a SUID anything program with public write
> permissions is a security disaster; and group should seldom have write
> permission, either. In fact, when it comes down to it, the owner
> doesn't really need write permission -- the owner can always fix the
> permissions immediately before modifying it. So, 4511 or 4555 is a
> more sensible set of permissions; 4755 would be wholly orthodox;
> anything more permissive is a bad idea.

I don't know in the end why I added "and removed if the directory...". Thanks for the correction.

By the way, the "oracle" executable needs SGID bit so a session through Oracle Net (SQL*Net) connection has sufficient permission. Owner bit is set to 7 for convenience when you need to re-make the executable (but as you said, the Makefile could just chmod right before it does its work). Other bit is set to 1 so others can't view the kernel symbols (by nm). These're all Oracle's decisions, not ours...

Yong Huang Received on Tue Nov 30 2004 - 09:20:27 CST