>
> However, an obvious question to ask at this point is why do it by
> hacking the ELF header? It's probably much simpler to have the
> executable explicitly drop capabilities by making an appropriate system
> call in the executable itself. This has the advantage that the kernel
> doesn't have to try to parse through the ELF sections looking for the
> capabilities-to-drop information, and possibily modifying ELF sections
> as well, which adds a *lot* of complexity.
>
As some other people (Albert Cahalan, for example) pointed out in this
thread, there are reasons for encoding the capability info in a header and
not in the code; for example, this gives _some_ sort of solution for
binary-only programs (even if they are `binary only' just because someone
doesn't want to recompile them...).
But, it seems that it may be a better idea to just change ld.so (instead
of the kernel) to find the capability note and reduce the process's
caps... It really doesn't belong in the kernel.
Hmm. I'll need to have a look at glibc 2.1's ld.so sometime.
-az
------------------------+----------------------------------------------------
. __ | Phone: +972 3 5340753 (home), +972 3 9685882 (work)
_| / | email: alonz@usa.net
/ | /_ Alon Ziv | smail: 33 Ha-Rama St., Ganey Tiqwah 55900, Israel
------------------------+----------------------------------------------------
<<<(((this place reserved for that ultra-wise oneliner I haven't found.)))>>>
-
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/