Jan Kiszka wrote:
> Hi,
> 
> I'm moving this thread to xenomai-core as I have some implementation idea...
> 
> Fillod Stephane wrote:
>> ...
>> I think Johan was not asking to disable the mlockall, but to allow some.
>> non-root user to be able to do it. He found his solution anyway, which
>> is worth an entry in the FAQ.
>>
>> Since it is going to be a FAQ for those people in embedded business,
>> some
>> tricks to allow non-root operation of mlockall, SCHED_FIFO, etc., would
>> be 
>> useful. For example, you may hack the commoncap in linux/security/, 
>> or a better solution would be to rely on realtime-lsm[1][2], thanks to 
>> the audio folks.
>>
>> [1] http://sourceforge.net/projects/realtime-lsm/
>> [2] http://lwn.net/Articles/110346/
>>
> 
> I think we could and should incorporate such a feature into the nucleus.
> 
> There is already code in xnshadow_map playing with cap_effective, but
> that happens too late. Instead, we should establish a group-based access
> control just like rt-lsm (the other knobs of that module are either
> irrelevant for Xenomai (mlock=0) or broken security-wise (any=1)) and
> raise the required caps for a process that belongs to the specified
> group, likely when an Xenomai interface gets attached by that process.

At this chance we should also remove CONFIG_XENO_OPT_SECURITY_ACCESS and
make the check mandatory. Due to the mlockall test, we effectively
demand raised privileges already. So there is no use in leaving other
Xenomai services open for non-privileged users.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to