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
Hi,
I'm currently looking at the feasibility of introducing one of the Linux
security models to an existing system which makes use of aufs in a couple
of places and I wanted to understand what sort of support there is in
place for security labels. Currently I'm looking at SELinux but it most
likel
18 matches
Mail list logo
