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, 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.
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
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core