Messages in this thread | | | Date | Mon, 12 Apr 1999 14:42:06 +0200 | From | Lars Marowsky-Bree <> | Subject | Re: ext3 to include capabilities? |
| |
On 1999-04-01T23:53:37, "Albert D. Cahalan" <acahalan@cs.uml.edu> said:
> You already have a setuid-root binary. > This hack lets you reduce it to be merely a capability-enhanced binary. > If you boot an old kernel, you are back to the original condition. > > With the other system, you simply must not ever use an old kernel. > You would have filesystem trouble (files you can't safely remove) > and general app failure (inability to use privs). At least my solution > lets you boot an old low-security kernel if you need to.
It would not behave like it is supposed to. This would just break compatibility, and this is not necessarily bad - not every enhancement needs to be backward compatible and run with an old kernel, what a deadend idea.
Lots of code does not work (as expected) when run with an older kernel. OTOH, old code should run as close as possible to the expected behaviour with a newer kernel.
Keeping compatibility is not always a good thing.
> Yes, we _could_ extend ext2. Then we need to extend everything else, > from NFS to tar. That includes non-Linux NFS servers.
Compatibility with tar would indeed need to be fixed, if you want it to store the additional flags. I see no way around this. Exporting binaries via NFS servers is problematic anyway and generally only useful between the same OS.
In short, I consider capabilities and a much finer grained access control a good thing. If we break compatibility to old code, so be it.
Sincerely, Lars Marowsky-Brée
-- Lars Marowsky-Brée Network Management
teuto.net Netzdienste GmbH - DPN Verbund-Partner
- 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/
| |