HI everyone,
I have resently installed a jail environment on my freebsd box, and had some
problems getting postgresql running under it.
After looking a bit on various mailinglists i figured out that I needed to
set jail.sysvipc_allowed to be 1 using sysctl in order to make postgresql
run.
However man jail gives me:
jail.sysvipc_allowed
This MIB entry determines whether or not processes within a jail
have access to System V IPC primitives. In the current jail
imple-
mentation, System V primitives share a single namespace across the
host and jail environments, meaning that processes within a jail
would be able to communicate with (and potentially interfere with)
processes outside of the jail, and in other jails. As such, this
functionality is disabled by default, but can be enabled by
setting
this MIB entry to 1.
Reading this it sounds like setting jail.sysvipc_allowed=1 is a bad idea?
So I guess my question is, whether it is a big security risk to run
postgresql in a jail? And what if I am running postgresql in both the host
environment and the jailed environment? Will I bee asking for troubles? I
managed to get things running, and so far I haven't had problems, but I was
wondering if it is safe to run postgresql + jail. I have seen an ISP
offering freebsd jails, and they have a list regarding downsides of running
jail (such as you can't use ICMP, shared hardware etc etc). In this list
they also includes that you can't run postgresql. This just makes me wonder
even more if this cocktail is a good idea :)
Cheers,
--
Michael Birkmose
Michael Sig Birkmose <birkmose@cs.auc.dk> wrote:
> I have resently installed a jail environment on my freebsd box, and had
some
> problems getting postgresql running under it.
> After looking a bit on various mailinglists i figured out that I needed to
> set jail.sysvipc_allowed to be 1 using sysctl in order to make postgresql
> run.
>
> However man jail gives me:
> [...]
In other words, shared memory and semaphores exist only
once on the machine, not per-jail. That means that a
process in a jail is not completely isolated from other
processes in other jails (or in the host environment)
which also use shared memory or semaphores.
> Reading this it sounds like setting jail.sysvipc_allowed=1 is a bad idea?
> So I guess my question is, whether it is a big security risk to run
> postgresql in a jail?
No, I wouldn't say that. It is still _much_ better than
not running PostgreSQL in a jail at all.
You can use the command "ipcs" to check the current usage
of shared memory and semaphores. Chances are that Post-
greSQL is the only program using them.
> And what if I am running postgresql in both the host
> environment and the jailed environment? Will I bee asking for troubles?
No, they will just each acquire and use their own shared
memory and semaphores. However, it doesn't make sense to
run more than one PostgreSQL instance on one machine.
In particular, why would you want to run only one of them
in a jail? Also note that running more than one instance
on a physical machine will lower the performance.
> I
> managed to get things running, and so far I haven't had problems, but
I was
> wondering if it is safe to run postgresql + jail. I have seen an ISP
> offering freebsd jails, and they have a list regarding downsides of
running
> jail (such as you can't use ICMP, shared hardware etc etc). In this
list
> they also includes that you can't run postgresql. This just makes me
wonder
> even more if this cocktail is a good idea :)
They decided not to set the sysctl, in order to improve
isolation. Probably a very good idea on a shell box.
I assume you don't intend to offer user shells on the
same machine running your PostgreSQL.
Apart from that, what would you do instead? Not run
PostgreSQL at all?
Regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 M?nchen
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"Documentation is like sex; when it's good, it's very, very good,
and when it's bad, it's better than nothing."
-- Dick Brandon
On Wed, 10 Sep 2003, Michael Sig Birkmose wrote: Hi,> So I guess my question is, whether it is a big security risk to run > postgresql in a jail?I once tested postgresql on a machine that I had used for testing some routing stuff before and therefor there no 127.0.0.1 had been configured on loopack but another IP. Some internal statistics sockets or s.th. like that (cannot really remember; PGSTAT ?) had been hardcoded to listen on 127.0.0.1 and postmaster did not start. And this will be a Problem with jails I guess: 127.0.0.1 gets mapped to the official IP of the jail. Thus those sockets will be reachable from outside the jail though they are set to 127 to not be reachable from outside. Jail breaks this design. I filed a bug report to postgresql people those days but I had been the only one ever complaining about this 127.0.0.1 so we agreed on closing it. I just found a 'diff' from those days that might help you to identify the code: --- postgresql-7.2.1.vanilla/./src/backend/postmaster/pgstat.c Thu Feb 7 23:20:26 2002 +++ postgresql-7.2.1/./src/backend/postmaster/pgstat.c Wed May 22 11:29:32 2002 @@ -183,7 +183,7 @@ */ pgStatAddr.sin_family = AF_INET; pgStatAddr.sin_port = htons(0); - inet_aton("127.0.0.1", &(pgStatAddr.sin_addr)); + inet_aton("127.0.0.1", &(pgStatAddr.sin_addr)); /* XXX FIXME */ alen = sizeof(pgStatAddr); if (bind(pgStatSock, (struct sockaddr *) & pgStatAddr, alen) < 0) { --- snipp --- Also found that a NOTE.txt next to it that tells me that I could stop this thing happening by turning stats collector of: stats_start_collector = false -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/