Ummm, why?
You gain so little (nothing?) over an executable header, and you lose
so much compatibility. You waste inode space and risk having buggy
filesystem code.
Better way:
1. Put capabilities information in the executable header.
2. Mark the executable setuid root.
3. Have the kernel check for #1 if #2, and prefer #1 if present.
Note that the result may or may not be setuid. In fact, the header
could contain a whole list of supplementary groups and an alternate
UID to be used instead of root or the user.
Note that we don't support privileged scripts anyway, and they could
be supported in userspace by an interpreter that looks for a header.
This is no worse than the existing setuid perl.
Advantages:
Works fine over NFS
Won't be trashed by an old fsck.ext2 or an old kernel
Preserved by existing tar, cpio, bru, taper, dump, etc.
Can be detected by old security scanner scripts
Old kernels can still run the software with old-style setuid
No new filesystem layout concerns (fragmentation)
-
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/