9eb9c9327563014ad6a807814e7975424642d5b9 |
|
19-Feb-2014 |
Stephen Smalley <sds@tycho.nsa.gov> |
Get rid of security_context_t and fix const declarations. 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>
/external/selinux/libselinux/src/compute_relabel.c
|
6a17cfaafcdab82c9909eccff56968913b36a631 |
|
14-Jun-2010 |
KaiGai Kohei <kaigai@ak.jp.nec.com> |
Author: KaiGai Kohei 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>
/external/selinux/libselinux/src/compute_relabel.c
|