Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Fri, 29 Jan 2016 22:24:35 +0000

> - 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.

No, this is not an EPICS IOC.  It is an EPICS Channel Access client.

Mark

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Till Straumann
Sent: Friday, January 29, 2016 3:55 PM
To: [email protected]
Subject: Re: set-user-id root and EPICS 3.15

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
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System