> 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 Managementteuto.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/