Jan Kiszka wrote:
> 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:
> 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).
no problem with the posix skin: the scheduling order is enforced by the
use of a semaphore.
Xenomai-core mailing list