On 10/01/2015 11:18 AM, Richard Haines wrote:
On Tuesday, 29 September 2015, 21:25, Stephen Smalley
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
p
> On Tuesday, 29 September 2015, 21:25, Stephen Smalley
> 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).
>
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 h
On Sunday, 27 September 2015, 23:24, Nir Soffer wrote:
>
>
>On Sun, Sep 27, 2015 at 3:06 PM, 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).
>>
On Sun, Sep 27, 2015 at 3:06 PM, Richard Haines <
richard_c_hai...@btinternet.com> 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 f
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
performa
