From: Kurtis H. <khe...@cs...> - 2011-12-02 00:18:24
|
I'd like to move all the runtime files (TMSITable, ChannelTable, Ephemeris, etc.) from /var/run to /tmp. This is to reduce the permissions hell I've now run into with RRLP server. How does everyone feel about that? |
From: David B. <da...@ra...> - 2011-12-02 00:34:52
|
As long as it's just a default-config thing, go for it. It just means we have to track differences in the .sql files in the commercial and public branches. On Dec 1, 2011, at 4:17 PM, Kurtis Heimerl wrote: > I'd like to move all the runtime files (TMSITable, ChannelTable, > Ephemeris, etc.) from /var/run to /tmp. This is to reduce the > permissions hell I've now run into with RRLP server. How does everyone > feel about that? > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > David A. Burgess Range Networks, Inc. 560 Brannan St. San Francisco, CA 94107 USA cell +1 707 208 2622 |
From: <su...@st...> - 2011-12-02 03:50:54
|
02.12.2011 08:17, Kurtis Heimerl пишет: > I'd like to move all the runtime files (TMSITable, ChannelTable, > Ephemeris, etc.) from /var/run to /tmp. This is to reduce the > permissions hell I've now run into with RRLP server. How does everyone > feel about that? Seems like both FHS violation and potential security risk: I wouldn't feel comfortable if user `nobody` will be able to modify TMSITable of my OpenBTS instance. Could you elaborate on what exactly causing this "hell"? I do not recall reading about other packages having same issues so it might be some deficiencies which we could try to fix. best regards, Max. |
From: Kurtis H. <khe...@cs...> - 2011-12-02 03:59:29
|
This is an absolutely valid point. Hrm. Basically, the RRLP server has two different users talking to it. First, there's the RRLP server instance, which is either going to run as root, the user, or openbts. Then there's a webserver/cgi-script that needs to touch some related files, that's going to run as apache. I wanted to avoid the need to create user groups to get around this particular concern. On Thu, Dec 1, 2011 at 7:50 PM, <su...@st...> wrote: > 02.12.2011 08:17, Kurtis Heimerl пишет: >> I'd like to move all the runtime files (TMSITable, ChannelTable, >> Ephemeris, etc.) from /var/run to /tmp. This is to reduce the >> permissions hell I've now run into with RRLP server. How does everyone >> feel about that? > > Seems like both FHS violation and potential security risk: I wouldn't feel > comfortable if user `nobody` will be able to modify TMSITable of my OpenBTS instance. > > Could you elaborate on what exactly causing this "hell"? > > I do not recall reading about other packages having same issues so it might be some > deficiencies which we could try to fix. > > best regards, > Max. > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss |
From: <su...@st...> - 2011-12-02 04:09:56
|
02.12.2011 11:58, Kurtis Heimerl пишет: > Basically, the RRLP server has two different users talking to it. > First, there's the RRLP server instance, which is either going to run > as root, the user, or openbts. Are you absolutely sure that it require root privileges? > Then there's a webserver/cgi-script > that needs to touch some related files, that's going to run as apache. > I wanted to avoid the need to create user groups to get around this > particular concern. Could you elaborate even more? Preferably with the links to some lines in source code so we don't have to stress our imagination too much :) Right now it's not really clear if "touch" actually mean "touch file" or read(file) or write(file). I think the issue at hands might be related to what's been bothering me for a while: there are no readily-available packages (.deb or .rpm or whatever you prefer) for OpenBTS. Yes, making them is additional efforts but it helps to resolve that kind of issues once and for all: file placement and permissions, users and groups creation and management - all those are really package manager job. cheers, Max. |
From: Kurtis H. <khe...@cs...> - 2011-12-02 04:21:27
|
On Thu, Dec 1, 2011 at 8:09 PM, <su...@st...> wrote: > 02.12.2011 11:58, Kurtis Heimerl пишет: >> Basically, the RRLP server has two different users talking to it. >> First, there's the RRLP server instance, which is either going to run >> as root, the user, or openbts. > > Are you absolutely sure that it require root privileges? Ah, no. As above, it can be run as root, user, or another openbts login. The point is that it's not apache. > >> Then there's a webserver/cgi-script >> that needs to touch some related files, that's going to run as apache. >> I wanted to avoid the need to create user groups to get around this >> particular concern. > > Could you elaborate even more? Preferably with the links to some lines in source code > so we don't have to stress our imagination too much :) > Right now it's not really clear if "touch" actually mean "touch file" or read(file) > or write(file). Unfortunately, i'm not exactly sure who is writing these files. My guess now is that only one account needs to do the writing, and it's not often. The code is in rrlpserver.erl, primarily. Unfortunately, i'm not on my dev box right now, so I can't peruse. > > I think the issue at hands might be related to what's been bothering me for a while: > there are no readily-available packages (.deb or .rpm or whatever you prefer) for > OpenBTS. Yes, making them is additional efforts but it helps to resolve that kind of > issues once and for all: file placement and permissions, users and groups creation > and management - all those are really package manager job. This also bothers me, but less than you'd think. It would help resolve some of these issues, but there's fundamentally a bad idea to build a "one-click" openbts system. This is licensed spectrum, users need to be doing things intentionally. Much of the configuration is designed to aide them in discovering their intent. This is intellectually similar to the "TX_ENABLE" flag in osmocombb. We don't want people to accidentally turn OpenBTS on, or to have it transmit in local bands. That's bad news. You're right that there's a lot we can do without crossing that bridge though. > > cheers, > Max. > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss |
From: <su...@st...> - 2011-12-02 09:10:06
|
02.12.2011 12:20, Kurtis Heimerl пишет: > This also bothers me, but less than you'd think. It would help resolve > some of these issues, but there's fundamentally a bad idea to build a > "one-click" openbts system. This is licensed spectrum, users need to > be doing things intentionally. Much of the configuration is designed > to aide them in discovering their intent. That's completely different story: having "1-click" installable and easily maintainable (hint: upgrade to future versions) system doesn't equals to have immediately operational system. Let alone the difference in equipment cost (osmocom requires two orders of magnitude less expensive hardware). > This is intellectually similar to the "TX_ENABLE" flag in osmocombb. > We don't want people to accidentally turn OpenBTS on, or to have it > transmit in local bands. That's bad news. The right analogue would be gConfig.defines("GSM.Transmit.Enable") variable which blocks any actual RF transmission by default. Max. |
From: Alexander C. <ale...@gm...> - 2011-12-16 18:44:35
|
On Fri, Dec 2, 2011 at 08:20, Kurtis Heimerl <khe...@cs...> wrote: > On Thu, Dec 1, 2011 at 8:09 PM, <su...@st...> wrote: >> 02.12.2011 11:58, Kurtis Heimerl пишет: >>> Basically, the RRLP server has two different users talking to it. >>> First, there's the RRLP server instance, which is either going to run >>> as root, the user, or openbts. >> >> Are you absolutely sure that it require root privileges? > > Ah, no. As above, it can be run as root, user, or another openbts > login. The point is that it's not apache. > >> >>> Then there's a webserver/cgi-script >>> that needs to touch some related files, that's going to run as apache. >>> I wanted to avoid the need to create user groups to get around this >>> particular concern. >> >> Could you elaborate even more? Preferably with the links to some lines in source code >> so we don't have to stress our imagination too much :) >> Right now it's not really clear if "touch" actually mean "touch file" or read(file) >> or write(file). > > Unfortunately, i'm not exactly sure who is writing these files. My > guess now is that only one account needs to do the writing, and it's > not often. The code is in rrlpserver.erl, primarily. Unfortunately, > i'm not on my dev box right now, so I can't peruse. > >> >> I think the issue at hands might be related to what's been bothering me for a while: >> there are no readily-available packages (.deb or .rpm or whatever you prefer) for >> OpenBTS. Yes, making them is additional efforts but it helps to resolve that kind of >> issues once and for all: file placement and permissions, users and groups creation >> and management - all those are really package manager job. > > This also bothers me, but less than you'd think. It would help resolve > some of these issues, but there's fundamentally a bad idea to build a > "one-click" openbts system. This is licensed spectrum, users need to > be doing things intentionally. Much of the configuration is designed > to aide them in discovering their intent. > > This is intellectually similar to the "TX_ENABLE" flag in osmocombb. > We don't want people to accidentally turn OpenBTS on, or to have it > transmit in local bands. That's bad news. > > You're right that there's a lot we can do without crossing that bridge though. Actually, asking "Which band and ARFCN to operate at?" and "Are you really sure you want to enable TX?" is also the packet manager's task. As well as providing safe defaults. E.g. many services like OpenVPN are provided OFF by default. You have to explicitly edit /etc/defaults to turn them on. -- Regards, Alexander Chemeris. |