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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: set-user-id root and EPICS 3.15 |
From: | Till Straumann <[email protected]> |
To: | [email protected] |
Date: | Fri, 29 Jan 2016 13:54:40 -0800 |
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 yougive 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