jon bird:
> The good news, firstly no kernel crash and secondly it looks like the
> labels are being propagated upwards correctly. My simple test program
:::
Glad to hear that.
Thank your for your test and report.
J. R. Okajima
In message <21252.1589106862@jrobl>, J. R. Okajima
writes
jon bird:
That would be useful yes. I should be picking up actively looking at
this again from Monday, I'll also be able to provide some more debug as
well.
Here you are (attached).
I started picking my way through this but there seem
jon bird:
> That would be useful yes. I should be picking up actively looking at
> this again from Monday, I'll also be able to provide some more debug as
> well.
Here you are (attached).
Please note that
- my environment is aufs4.14 on debian 10 buster.
- you will need to some modification to ap
In message <1859.1589054580@jrobl>, J. R. Okajima
writes
"J. R. Okajima":
Unfortunately this Call Trace looks unreliable, and I cannot see the
behaviour exactly. But I can assume that there is a call chain such
like this.
- "ls" issues lgetxattr(2)
+ SyS_lgetxattr()
+ aufs_getxattr()
"J. R. Okajima":
> Unfortunately this Call Trace looks unreliable, and I cannot see the
> behaviour exactly. But I can assume that there is a call chain such
> like this.
> - "ls" issues lgetxattr(2)
> + SyS_lgetxattr()
> + aufs_getxattr()
> + au_lgxattr()
> + si_read_lock()
I
Thank you very much for the report.
"jon bird":
> Attempting to do a "ls" of the mount, the console hung and I had to reboot
> it to recover. I've now enabled AUFS_DEBUG in the kernel and tried again.
> This time I triggered a kernel BUG:
If you can, please try enabling these too.
CONFIG_DEBUG_ST
> "jon bird":
>> Thanks for your assistance with this, for completeness I will post back
>> if
>> I have any success getting it to work in case anyone else is trying to
>> do
>> something similar.
>
> Such report will be appricated. I will, even if no one will.
> It will be a good test to see ho
"jon bird":
> Thanks for your assistance with this, for completeness I will post back if
> I have any success getting it to work in case anyone else is trying to do
> something similar.
Such report will be appricated. I will, even if no one will.
It will be a good test to see how good or bad aufs
> "jon bird":
>> Apologies, meant to answer that question yesterday. Our system is an
>> embedded, highly cut down build of Linux and whilst we have the core
>> policy tools deployed, seinfo is part of the SETools suite which we
>> don't
>> have available. It's possible I may be able to look at d
"jon bird":
> Apologies, meant to answer that question yesterday. Our system is an
> embedded, highly cut down build of Linux and whilst we have the core
> policy tools deployed, seinfo is part of the SETools suite which we don't
> have available. It's possible I may be able to look at deploying it
Hi Junjiro,
> "jon bird":
>> See below for info:
>
> Thanx.
>
>
>> As described above. You obviously need an SELinux enabled system, with
>> the
>> policy tools. I have a very basic security policy which I can supply for
>> testing with this if necessary.
>
> Would you describe more about the very
"jon bird":
> See below for info:
Thanx.
> As described above. You obviously need an SELinux enabled system, with the
> policy tools. I have a very basic security policy which I can supply for
> testing with this if necessary.
Would you describe more about the very basic security policy?
Does i
See below for info:
>
>
>> That said, I did start having a bit of an explore as to where the
>> message
>> "not configured for labeling" was coming from. As best I can fathom it's
>> from within security/selinux/hooks.c and there is a block of code which
>> is
>> as follows:
>>
>> if (!sbsec-
> > if (!sbsec->behavior) {
> :::
> > The message itself is emitted based on the value of 'sbsec->behavior'
> > which I think should (may?) be SECURITY_FS_USE_XATTR.
>
> Ok, then when and who should set a correct value to sbsec->behavior?
It might be selinux policy.
If you have 'seinfo'
"jon bird":
> I did indeed take a look at this and concluded that I didn't think I'd
> need them (if at all) at this point however I have just tried using both
> icexsec and then for good measure icex on the mount, neither made any
> noticeable difference:
Then let's forget about ICEX for now, and
Hi Junjiro,
Thanks for getting back to me.
> Hello Jon,
>
> "jon bird":
>> Support for XATTR/EA (including Security Labels)
>>
>> Which implies some sort is now available. The help for this reads:
>>
>> If your branch fs supports XATTR/EA and you want to make them available
>> in
>> aufs too, the
Hello Jon,
"jon bird":
> Support for XATTR/EA (including Security Labels)
>
> Which implies some sort is now available. The help for this reads:
>
> If your branch fs supports XATTR/EA and you want to make them available in
> aufs too, then enable this opsion and specify the branch attributes for
17 matches
Mail list logo
