I've opened a ticket for this [1]. Personally, I agree with Till's
sentiments. RT scheduling w/o protection from VM faults... isn't.
Also, the idea of running something like SPEC as root scares me. I
would encourage Gerry to investigate Linux capabilities.
That said, I don't think it's reasonable that we ask all downstream uses
of libCom to change the way they run their applications.
Since the issue now, and previously [2], is with non-IOC users of libCom
I will repeat my suggestion that the call to mlockall() be moved into
iocInit().
Michael
[1] https://bugs.launchpad.net/epics-base/+bug/1539791
[2] http://www.aps.anl.gov/epics/tech-talk/2015/msg01811.php
On 01/29/2016 04:54 PM, Till Straumann wrote:
> In my opinion (which is biased as this change was driven by myself
> and my colleagues) the current implementation is just fine and no
> change is required.
>
> These would be my arguments:
>
> - it doesn't make much sense to use RT scheduling w/o memory locking
> as this would hurt determinism. Thus, selectively disabling mlockall()
> is a poor work-around.
>
> - the code uses these features (RT scheduling + mlockall) *only* if you
> give it sufficient privilege to use them. If it has the privileges
> then the
> code assumes you want it to use them.
>
> In any normal scenario EPICS is run as a normal user who by default
> (on any common distro) does not have the privilege to use RT.
>
> We set up our systems to grant the necessary users with a sufficient
> hard limit but keep the soft limit (ulimit) zero. Thus, such a user can
> selectively raise the ulimit and start a RT process.
>
> - running an EPICS ioc as root (setuid) is what is causing the problem
> for the poster. I would contend that this is not the common scenario.
>
> IMHO better approaches to solving Gerry's problems would be:
>
> - use capabilities(7) to grant the executable iopl permission. This is
> less drastic than setuid. (setcap cap_sys_rawio)
>
> - make sure root privilege is dropped before setscheduler/mlockall are
> attempted.
>
> Let's see: We are talking about introducing a special hack (setenv
> xxx) to
> be necessary for memory locking while you already are able to use
> SCHED_FIFO
> and all of this because you want to be able to run EPICS as setuid?
> Really?
>
> If anything I'd add a variable which is the run-time equivalent of
> USE_POSIX_THREAD_PRIORITY_SCHEDULING and default it to NO.
>
> - Till
>
> On 01/29/2016 12:55 PM, Andrew Johnson wrote:
>> On 01/28/2016 08:43 AM, Ralph Lange wrote:
>>> However, this is the second time that we hear of trouble because people
>>> are running client applications (i.e. CA clients) in real-time context.
>>> In those cases, the memory locking might not be intended nor useful.
>>> There is no way for the OS abstraction layer (where the memlock
>>> happens)
>>> to know if the caller is an IOC type or a client type application.
>>> We already began to reconsider the automatic activation feature.
>> I think it would be reasonable to require those that want the mlockall()
>> behaviour to configure it. The main question would be whether this
>> should be configurable at build-time, or if it can require a run-time
>> setting. The simplest fix would be something like this:
>>
>> === modified file 'src/libCom/osi/os/posix/osdThread.c'
>> --- src/libCom/osi/os/posix/osdThread.c 2015-03-19 15:22:15 +0000
>> +++ src/libCom/osi/os/posix/osdThread.c 2016-01-29 20:41:08 +0000
>> @@ -362,7 +362,8 @@
>> fprintf(stderr, "LRT: min priority: %d max priority %d\n",
>> pcommonAttr->minPriority, pcommonAttr->maxPriority);
>> }
>> - if (pcommonAttr->maxPriority > pcommonAttr->minPriority) {
>> + if (getenv("EPICS_RT_MLOCKALL") &&
>> + pcommonAttr->maxPriority > pcommonAttr->minPriority) {
>> status = mlockall(MCL_CURRENT | MCL_FUTURE);
>> if(status) {
>> fprintf(stderr, "Unable to lock the virtual address space
>> using mlockall\n");
>>
>> That would require IOCs that need the memory locking to have set the
>> EPICS_RT_MLOCKALL environment variable before they are executed. A
>> slightly more complicated solution would allow locking to be turned on
>> at build-time in the configure/CONFIG_SITE_ENV file, but it could be
>> turned off again at run-time with an environment variable.
>>
>> If you currently rely on the current mlockall() behaviour of Base and
>> wish to influence our decision, please speak up before we commit any
>> changes.
>>
>> - Andrew
>>
>
- References:
- set-user-id root and EPICS 3.15 Gerry Swislow
- RE: set-user-id root and EPICS 3.15 Mark Rivers
- Re: set-user-id root and EPICS 3.15 Ralph Lange
- Re: set-user-id root and EPICS 3.15 Andrew Johnson
- Re: set-user-id root and EPICS 3.15 Till Straumann
- Navigate by Date:
- Prev:
RE: set-user-id root and EPICS 3.15 Mark Rivers
- Next:
Re: set-user-id root and EPICS 3.15 J. Lewis Muir
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: set-user-id root and EPICS 3.15 Mark Rivers
- Next:
Re: set-user-id root and EPICS 3.15 J. Lewis Muir
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
<2016>
2017
2018
2019
2020
2021
2022
2023
2024
|