On Thu, 2005-11-03 at 10:05 -0500, Ivan Gyurdiev wrote:
> Chances are that if something's possible without a warning, someone will
> eventually do it...
> Also, it seems rather confusing to me to have two data structures for
> the same thing
> (not to mention the 2+ other ones used in sepol/semanage).
Hysterical raisins, er historical reasons.
security_context_t was the original type, a string representation of the
security attributes that could be handled by the kernel and applications
without tying them to a specific security model. Only the security
server could truly interpret the content (relative to a given policy),
and only SELinux code (libselinux or kernel security server) could even
interpret the format (e.g. breaking out the fields).
The separate context structure type was introduced to allow
security-aware applications to further manipulate the individual fields
without needing to know the internal format of the string. Naturally,
you can extract the string from the structure, so one could have then
replaced all direct uses of the string with the struct, but I don't
think that would be optimal; plenty of applications only want to deal
with the string. ls -Z, ps -Z, mkdir -Z, ...
As you know, libsepol was a much later creation from the core
checkpolicy code (which in turn was derived from the security server
code), and is for policy manipulation rather than interacting with the
SELinux kernel.
--
Stephen Smalley
National Security Agency
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
