Re: [RFC PATCH V2] libselinux: Add selinux_restorecon function

[Richard Haines <richard_c_haines@btinternet.com>]

> On Tuesday, 29 September 2015, 21:25, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On 09/27/2015 08:06 AM, Richard Haines wrote:
>>  The selinux_restorecon(3) man page details this function that relies
>>  on the selabel_digest(3) function available from [1] (as not yet
>>  part of upstream libselinux).
>> 
>>  It has been built using the work from Android where an SHA1 hash
>>  of the specfiles is held in an extended attribute to enhance
>>  performance. Also contains components from policycoreutils/setfiles.
>> 
>>  The utils/selinux_restorecon.c utility demonstrates the functionality.
>> 
>>  [1] http://marc.info/?l=selinux&m=144274383217343&w=2
>> 
>>  Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>

>>  ---
------------ snip --------------
>>  +
>>  +extern int selinux_restorecon(const char **pathname_list,
>>  +                    const char **exclude_list,
>>  +                    const char *fc_path,
>>  +                    unsigned int restorecon_flags);
> 

> This is a more cumbersome interface for typical users than the Android one.

To make this easier would you prefer it to just take a single pathname and the
flags (and maybe the fc_path as well, or add another interface to take it as
discussed below)

The only reason I put the exclude_list is to allow filesystems that don't have
xattr support to be excluded by the caller. This could probably be resolved by
always setting the FTS_XDEV flag with the caller ensuring they cover their
relevant filesystems.

---------------- snip ----------------------

>>  +    fc_sehandle = selabel_open(SELABEL_CTX_FILE, fc_opts, 
> NUM_SELABEL_OPTS);
>>  +    if (!fc_sehandle) {
>>  +        selinux_log(SELINUX_ERROR,
>>  +                "Error obtaining file context handle: %s\n",
>>  +                            strerror(errno));
>>  +        return -1;
>>  +    }
> 
> Android only does this once, not on every call to restorecon.
> Caller that wants to use selabel_open() itself with custom options can 
> use selinux_android_set_sethandle() after selabel_open() call; 

> otherwise, callers don't ever have to specify selabel_open() args.

I could implement a similar interface to selinux_android_file_context_handle
(I guess that is what you are referring to) that would also take the fc_path
if this would be useful, it then keep selinux_restorecon simple and in line
with Android.

>