commit 1f89c4e787 ("libselinux: Eliminate
use of security_compute_user()") eliminated the use of
security_compute_user() by get_ordered_context_list(). Deprecate
all use of security_compute_user() by updating the headers and man
pages and logging a warning message on any calls to it. Remove
the example utility that called the interface. While here, also
fix the documentation of correct usage of the user argument to these
interfaces.
Fixes: https://github.com/SELinuxProject/selinux/issues/70
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: Petr Lautrbach <plautrba@redhat.com>
Makes libselinux safer and less likely to leak file descriptors when
used as part of a multithreaded program.
Signed-off-by: Nick Kralevich <nnk@google.com>
In attempting to enable building various part of Android with -Wall -Werror,
we found that the const security_context_t declarations in libselinux
are incorrect; const char * was intended, but const security_context_t
translates to char * const and triggers warnings on passing
const char * from the caller. Easiest fix is to replace them all with
const char *. And while we are at it, just get rid of all usage of
security_context_t itself as it adds no value - there is no true
encapsulation of the security context strings and callers already
directly use string functions on them. typedef left to permit
building legacy users until such a time as all are updated.
This is a port of Change-Id I2f9df7bb9f575f76024c3e5f5b660345da2931a7
from Android, augmented to deal with all of the other code in upstream
libselinux and updating the man pages too.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: Eric Paris <eparis@redhat.com>
Email: kaigai@ak.jp.nec.com
Subject: libselinux APIs should take "const" qualifier?
Date: Tue, 23 Mar 2010 11:56:36 +0900
(2010/03/19 22:32), Stephen Smalley wrote:
> On Fri, 2010-03-19 at 16:52 +0900, KaiGai Kohei wrote:
>> Right now, security_context_t is an alias of char *, declared in selinux.h.
>>
>> Various kind of libselinux API takes security_context_t arguments,
>> however, it is inconvenience in several situations.
>>
>> For example, the following query is parsed, then delivered to access
>> control subsystem with the security context as "const char *" cstring.
>>
>> ALTER TABLE my_tbl SECURITY LABEL TO 'system_u:object_r:sepgsql_table_t:SystemHigh';
>> const char *<---- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> In this case, we want to call selinux_trans_to_raw_context() to translate
>> the given security context into raw format. But it takes security_context_t
>> argument for the source context, although this pointer is read-only.
>> In the result, compiler raises warnings because we gave "const char *" pointer
>> into functions which take security_context_t (= char *).
>>
>> Any comments?
>>
>> It seems to me the following functions' prototype should be qualified by
>> "const".
>
> That seems reasonable and should have no impact on library ABI.
> On the other hand, others have pointed out that security_context_t is
> not a properly encapsulated data type at all, and perhaps should be
> deprecated and replaced with direct use of char*/const char* throughout.
>
> There are other library API issues as well that have come up in the
> past, such as lack of adequate namespacing (with approaches put forth),
> but we don't ever seem to get a round tuit.
At first, I tried to add const qualifiers read-only security_context_t
pointers, but didn't replace them by char */const char * yet, right now.
BTW, I could find out the following code:
int security_compute_create(security_context_t scon,
security_context_t tcon,
security_class_t tclass,
security_context_t * newcon)
{
int ret;
security_context_t rscon = scon;
security_context_t rtcon = tcon;
security_context_t rnewcon;
if (selinux_trans_to_raw_context(scon, &rscon))
return -1;
if (selinux_trans_to_raw_context(tcon, &rtcon)) {
freecon(rscon);
return -1;
}
:
In this case, scon and tcon can be qualified by const, and the first
argument of selinux_trans_to_raw_context() can take const pointer.
But it tries to initialize rscon and tscon by const pointer, although
these are used to store raw security contexts.
The selinux_trans_to_raw_context() always set dynamically allocated
text string on the second argument, so we don't need to initialize it
anyway. I also removed these initializations in this patch.
Does the older mcstrans code could return without allocation of raw
format when the given scon is already raw format? I don't know why
these are initialized in this manner.
Thanks.
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
Signed-off-by: Chad Sellers <csellers@tresys.com>
