On 07/08/2019 05:34, John Johansen wrote:
> name="apparmor/.null" says that it is an fd that was inherited and apparmor
> did a
> revalidation on it and the access was denied so the fd was duped to a special
> null
> device files instead of out right closing it (there are good reasons for
> doin
On 8/6/19 7:36 PM, Mikhail Morfikov wrote:
> On 07/08/2019 00:24, Seth Arnold wrote:
>> - run both processes in the same filesystem namespace, so files have names
>> that are meaningful to both
>>
>
> I though they both run in the same filesystem namespace.
> It's just /usr/sbin/deluser which e
On 07/08/2019 00:24, Seth Arnold wrote:
> - run both processes in the same filesystem namespace, so files have names
> that are meaningful to both
>
I though they both run in the same filesystem namespace.
It's just /usr/sbin/deluser which executes /usr/sbin/userdel .
Here are the two profile
On Tue, Aug 06, 2019 at 01:36:23PM +0200, Mikhail Morfikov wrote:
> apparmor="DENIED" operation="getattr" info="Failed name lookup -
> disconnected path" error=-13 profile="app2" \ name="apparmor/.null"
> pid=55644 comm="app2" requested_mask="r" denied_mask="r" fsuid=1 ouid=0
>
> So when the confi
I have two apps: *app1* and *app2*, and *app1* calls/executes *app2* at
some point in time.
When I create an AppArmor profile for *app2* only, the *app2* works
well, and there's no problem with its confinement. When now I create an
AppArmor profile for *app1* and inside of this profile I use
"/
