Re: [Xenomai-core] Group-based RT caps

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2664 bytes --]

Jan Kiszka wrote:
> 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.
> 
> Comments? Volunteer coders...?

I couldn't resist, the approach looked too simple and appealing:

http://www.rts.uni-hannover.de/rtaddon/patches/xenomai/rt-caps-group.patch

Actually, it's even more advanced than realtime-lsm in so far as it also
checks for secondary group membership. You can use the nucleus module
parameter "xenomai_gid" to control the Xenomai group, also during
runtime using /sys.

Works nicely for me. I'm able to run testsuite programs under my user
account that now additionally belongs to the "xenomai" group. :)

One issue popped up and costed some nerves: linuxthreads-based
pthread_create() (non-NPTL glibc, uClibc) with SCHED_FIFO/RR attribute
fails already in userland because that library overeagerly checks for
root permissions. This is now worked around, but maybe not in the
cleanest way as it changes the initial thread scheduling order (more
problematic for the POSIX skin than for Native).


*BIG FAT WARNING*
Don't believe that this patch allows to run Xenomai applications in
whatever securely confined way! We grant CAP_SYS_RAWIO to all Xenomai
users, some Xenomai services can easily be corrupted/exploited from user
space (those based on shared heaps e.g.), and no one audits the core or
all the drivers for security. The advantage of having a separate Xenomai
group instead of just assigning root access directly is being able to
avoid _accidental_ changes, nothing more!

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]