>
> I have to wonder, just how many setuid executables do people have?
> Implementing filesystem capability bits in ramfs or tmpfs might do
> the job. At boot, initramfs stuff puts a few trusted executables
> in /trusted and sets the capability bits. Then "mount --bind" to
> put /trusted/su over an empty /bin/su file, or use symlinks.
It's more useful that you might at first think, in terms of applications.
If I have an app I want to make available to a limited group, currently I
can portably make the file setuid to app-owner, then group but not world
executable, and the people in the group can have access. The app might be
a database, usenet news, mail system spam filter, whatever. ACLs work, but
are not widely portable at the moment (if ever).
> One might as well make "nosuid" the default then, and mount the
> root filesystem that way. It's not as if a system needs to have
> gigabytes of setuid executables.
Well, my point here is not that you can't do this, but that normal users
may have legitimate reasons for doing this, and that it's desirable to
avoid having to remount the filesystem to reload some setuid file list.
I would think a mount option which blocks setuid on root owned files and
files which are world writable would be useful. That would allow the
mounting of applications, which people in practice do, without
compromising the whole system.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/