> I understand that. Read my concern again. I don't understand how
> your system can possibly make my (already installed) 2.0.x kernel
> ignore the setuid bit. I have 2.0.x around for stability, so putting
> random patches into it isn't really an option. It seems like your
> system will run programs with capabilities on 2.2.x but full-blown
> setuid on 2.2.x, which opens up the security holes I'm concerned
~~~~~ 2.0.x
> about
Ok. So use what other people proposed: make that program setuid _but_
_not_ _executable_.
And then learn 2.2.x kernel to launch non-executable files if they
have suid bit set, are root-owned and contain capability-enhanced
headers. [It is ugly. Being able to execute something which does not
have executable bit set is ugly. But it should work.]
Pavel
> Basically, it seems like your system doesn't allow a secure fallback
> for 2.0.x machines. It promotes capabilities-having bins to suid
> ones under old kernels, which is a major bug IMO.
Look above.
> (second, less interesting portion of debate snipped -- adding EUID/
> UID/FSUID/SUID fields to the header solves that problem in kernels
> that grok the scheme, but has the same issue of causing older kernels
> to grant suid root to binaries that only want limited privs).
>
> Your idea does limit the fs data needed to one bit, and that's
> something I don't mind. Using the suid bit as you suggest is
> bogus, though. The sticky bit would work if it were limited to root,
> but that's not an assumption that's workable in an NFS environment
> (correct me if I'm wrong).
-- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/