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, thanks to >> the audio folks. >> >>  http://sourceforge.net/projects/realtime-lsm/ >>  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
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core