On 8/1/2018 3:18 AM, Martin Townsend wrote:
> Hi,
>
> I have a service running with a SmackProcessLabel that uses the
> supervisory watchdog feature, ie calls sd_notify(). The Watchdog
> keeps resetting the service and I get the following in the journal
>
> Jul 27 11:36:11 kernel: audit: type=1400
smack label will run with this attribute's value"? smack
>>>> labels "run"? That sentence makes no sense to me at all...
>>>>
>>>> Again, what kind of objects are SMACK64 and SMACK64EXEC applied to?
>>>> files? processes?
>>
;> I am sorry, but I cannot parse this.
>>
>> "The smack label will run with this attribute's value"? smack
>> labels "run"? That sentence makes no sense to me at all...
>>
>> Again, what kind of objects are SMACK64 and SMACK64EXEC applied to?
un"? That sentence makes no sense to me at all...
>>>
>>> Again, what kind of objects are SMACK64 and SMACK64EXEC applied to?
>>> files? processes?
>> Sorry, I'm also confused.
>> OK, I asked some about this to my security friend.
>> And I add Casey
On 5/11/2011 1:40 PM, Eric Paris wrote:
> On Wed, May 11, 2011 at 4:22 PM, Greg KH wrote:
>> On Wed, May 11, 2011 at 04:14:32PM -0400, Eric Paris wrote:
>>> On Wed, May 11, 2011 at 3:56 PM, Greg KH wrote:
>>>> On Wed, May 11, 2011 at 10:14:40AM -0700, Casey Schaufl
On 5/11/2011 12:56 PM, Greg KH wrote:
> On Wed, May 11, 2011 at 10:14:40AM -0700, Casey Schaufler wrote:
>> I would prefer /sys/security for all LSMs, but if SELinux goes with /sys/fs
>> Smack will likely follow on the theory that mirroring the current dominant
>> LSM is more
t;>>>> On Wed, May 11, 2011 at 15:54, Greg KH wrote:
>>>>>> On Wed, May 11, 2011 at 01:22:42PM +0200, John Johansen wrote:
>>>>>>> On 05/11/2011 03:59 AM, Greg KH wrote:
>>>>>>>> On Tue, May 10, 2011 at 03:55:24PM -
gt;>>> On Tue, May 10, 2011 at 03:55:24PM -0700, Casey Schaufler wrote:
>>>>>> On 5/10/2011 3:34 PM, Greg KH wrote:
>>>>>>> From: Greg Kroah-Hartman
>>>>>>>
>>>>>>> In the interest of keeping userspace from ha
On 5/10/2011 3:34 PM, Greg KH wrote:
> From: Greg Kroah-Hartman
>
> In the interest of keeping userspace from having to create new root
> filesystems all the time, let's follow the lead of the other in-kernel
> filesystems and provide a proper mount point for it in sysfs.
>
> For selinuxfs, this m
