Securing "make check" (CVE-2014-0067)
As announced with last week's releases, use of trust authentication in the
"make check" temporary database cluster makes it straightforward to hijack the
OS user account involved. The prerequisite is another user account on the
same system. The solution we discussed on security@postgresql.org was to
switch to md5 authentication with a generated, strong password.
This patch adds a pg_genpassword program, which pg_regress.c and the
pg_upgrade test drivers use to generate password files for initdb and psql.
It is essentially a portable "head -c16 /dev/urandom | xxd -p". I have it
installing to $(bindir) for the benefit of out-of-tree test suites that create
temporary clusters. $(pgxsdir)/$(subdir), where we install pg_regress itself,
was another candidate. This is the first core need for high-entropy random
sequences, so I adapted px_acquire_system_randomness() to libpgport as
secure_rand_bytes().
The implementation of secure_rand_bytes() prompted the question of what to do
when there's no adequate entropy source, such as on Unix-like systems with no
/dev/urandom. OpenSSL and OpenSSH give up; you're expected to install EGD or
PRNGD. I made the test drivers recognize a PGTESTPWFILE environment variable.
It should name a file suitable as input to "initdb --pwfile=...". When
present, the test drivers will skip attempting to generate a password and will
use the one in that file. I don't see any platforms on the buildfarm that
will need to use PGTESTPWFILE, but I bet at least Tom's old HP-UX system will
need it.
The dblink and postgres_fdw tests rely on a postmaster environment such that
superuser sessions can make new bootstrap superuser connections without a
password. pg_regress achieves this by starting the server with the same
PGPASSFILE setting as it uses for psql. Secure "make -C contrib installcheck"
rigs will need to do something similar.
Needing some conversion from random bytes to a text password, I moved the hex
encoder from encode.c to src/port/pgencode.c. That place will be suitable for
the base64 encoder, too, when other code needs it (pgcrypto already contains a
duplicate base64 implementation). Though the new libpgport functions fit
better in libpgcommon, since this is slated for back-patch, I chose the
library available in all supported versions.
Peripheral to the topic at hand, I sought and did not find evidence of
contemporary systems where an unprivileged user can examine the environment
variables of another user's processes. What's a non-ancient system for which
the warning documented for the PGPASSWORD environment variable is apropos?
Thanks,
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
Attachments:
makecheck-secure-v3.patchtext/plain; charset=us-asciiDownload+739-180
I didn't check the patch in detail, but it seems to me that both the
encode stuff as well as pgrand belong in src/common rather than
src/port.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Mar 01, 2014 at 12:48:08PM -0300, Alvaro Herrera wrote:
I didn't check the patch in detail, but it seems to me that both the
encode stuff as well as pgrand belong in src/common rather than
src/port.
Since src/common exists only in 9.3 and up, that would mean putting them in
different libraries depending on the branch. I did not think that worthwhile.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
As announced with last week's releases, use of trust authentication in the
"make check" temporary database cluster makes it straightforward to hijack the
OS user account involved. The prerequisite is another user account on the
same system. The solution we discussed on security@postgresql.org was to
switch to md5 authentication with a generated, strong password.
Noah is leaving the impression that there was consensus on that approach;
there was not, which is one reason that this patch didn't simply get
committed last week.
There are two big problems with the lets-generate-a-random-password
approach. Noah acknowledged the portability issue of possibly not having
a strong entropy source available. The other issue though is whether
doing this doesn't introduce enough crypto dependency into the core code
to create an export-restrictions hazard. We've kept contrib/pgcrypto
out of core all these years in order to give people a relatively
straightforward solution if they are worried about export laws: just omit
contrib/pgcrypto. But "just omit regression testing" isn't palatable.
In the case of Unix systems, there is a *far* simpler and more portable
solution technique, which is to tell the test postmaster to put its socket
in some non-world-accessible directory created by the test scaffolding.
Of course that doesn't work for Windows, which is why we looked at the
random-password solution. But I wonder whether we shouldn't use the
nonstandard-socket-location approach everywhere else, and only use random
passwords on Windows. That would greatly reduce the number of cases to
worry about for portability of the password-generation code; and perhaps
we could also push the crypto issue into reliance on some Windows-supplied
functionality (though I'm just speculating about that part).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/01/2014 12:29 PM, Tom Lane wrote:
In the case of Unix systems, there is a *far* simpler and more portable
solution technique, which is to tell the test postmaster to put its socket
in some non-world-accessible directory created by the test scaffolding.
+1 - I'm all for KISS.
Of course that doesn't work for Windows, which is why we looked at the
random-password solution. But I wonder whether we shouldn't use the
nonstandard-socket-location approach everywhere else, and only use random
passwords on Windows. That would greatly reduce the number of cases to
worry about for portability of the password-generation code; and perhaps
we could also push the crypto issue into reliance on some Windows-supplied
functionality (though I'm just speculating about that part).
See for example
<http://msdn.microsoft.com/en-us/library/windows/desktop/aa379942%28v=vs.85%29.aspx>
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Mar 1, 2014 at 7:09 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
On 03/01/2014 12:29 PM, Tom Lane wrote:
In the case of Unix systems, there is a *far* simpler and more portable
solution technique, which is to tell the test postmaster to put its socket
in some non-world-accessible directory created by the test scaffolding.+1 - I'm all for KISS.
Of course that doesn't work for Windows, which is why we looked at the
random-password solution. But I wonder whether we shouldn't use the
nonstandard-socket-location approach everywhere else, and only use random
passwords on Windows. That would greatly reduce the number of cases to
worry about for portability of the password-generation code; and perhaps
we could also push the crypto issue into reliance on some Windows-supplied
functionality (though I'm just speculating about that part).See for example <http://msdn.microsoft.com/en-us/library/windows/desktop/
aa379942%28v=vs.85%29.aspx>
For a one-off password used locally only, we could also consider just using
a guid, and generate it using
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379205(v=vs.85).aspx.
Obviously windows only though - do we have *any* Unix platforms that can't
do unix sockets?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Sat, Mar 01, 2014 at 12:29:38PM -0500, Tom Lane wrote:
There are two big problems with the lets-generate-a-random-password
approach. Noah acknowledged the portability issue of possibly not having
a strong entropy source available. The other issue though is whether
doing this doesn't introduce enough crypto dependency into the core code
to create an export-restrictions hazard. We've kept contrib/pgcrypto
out of core all these years in order to give people a relatively
straightforward solution if they are worried about export laws: just omit
contrib/pgcrypto. But "just omit regression testing" isn't palatable.
If pgrand.c poses an export control problem, then be-secure.c poses a greater
one. pgrand.c is just glue to an OS-provided CSPRNG.
In the case of Unix systems, there is a *far* simpler and more portable
solution technique, which is to tell the test postmaster to put its socket
in some non-world-accessible directory created by the test scaffolding.Of course that doesn't work for Windows, which is why we looked at the
random-password solution. But I wonder whether we shouldn't use the
nonstandard-socket-location approach everywhere else, and only use random
passwords on Windows. That would greatly reduce the number of cases to
worry about for portability of the password-generation code;
Further worrying about systems lacking /dev/urandom is a waste of time. They
will only get less common, and they are already rare enough that we have zero
of them on the buildfarm. I provided them with a straightforward workaround:
point the PGTESTPWFILE environment variable to a file containing a password.
Having that said, I can appreciate the value of tightening the socket mode for
a bit of *extra* safety:
--- a/src/test/regress/pg_regress.c
+++ b/src/test/regress/pg_regress.c
@@ -2299,4 +2299,5 @@ regression_main(int argc, char *argv[], init_function ifunc, test_function tfunc
fputs("\n# Configuration added by pg_regress\n\n", pg_conf);
fputs("max_prepared_transactions = 2\n", pg_conf);
+ fputs("unix_socket_permissions = 0700\n", pg_conf);Taking the further step of retaining trust authentication on Unix would make
it easier to commit tests guaranteed to fail on Windows. I see no benefit
cancelling that out.
and perhaps
we could also push the crypto issue into reliance on some Windows-supplied
functionality (though I'm just speculating about that part).
Every version of the patch has done it that way. It has used OS-supplied
cryptography on every platform.
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
In the case of Unix systems, there is a *far* simpler and more portable
solution technique, which is to tell the test postmaster to put its socket
in some non-world-accessible directory created by the test scaffolding.
Yes, yes, yes.
Of course that doesn't work for Windows, which is why we looked at the
random-password solution. But I wonder whether we shouldn't use the
nonstandard-socket-location approach everywhere else, and only use random
passwords on Windows. That would greatly reduce the number of cases to
worry about for portability of the password-generation code; and perhaps
we could also push the crypto issue into reliance on some Windows-supplied
functionality (though I'm just speculating about that part).
Multi-user Windows build systems are *far* more rare than unix
equivilants (though even those are semi-rare in these days w/ all the
VMs running around, but still, you may have University common unix
systems with students building PG- the same just doesn't exist in my
experience on the Windows side).
Thanks,
Stephen
Magnus Hagander <magnus@hagander.net> writes:
For a one-off password used locally only, we could also consider just using
a guid, and generate it using
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379205(v=vs.85).aspx.
Not sure if that API is intended to create an unpredictable UUID, rather
than just a unique one.
Obviously windows only though - do we have *any* Unix platforms that can't
do unix sockets?
I'm not aware of any. A look into the git history of pg_config_manual.h
shows that QNX and BEOS used to be marked as not having Unix sockets,
but of course we dropped support for those in 2006. I'd rather bet on
"all non-Windows platforms have Unix sockets" than "all non-Windows
platforms have /dev/urandom"; the former standard is far older than
the latter.
One other thought here: is it actually reasonable to expend a lot of effort
on the Windows case? I'm not aware that people normally expect a Windows
box to have multiple users at all, let alone non-mutually-trusting users.
BTW, a different problem with the proposed patch is that it changes
some test cases in ecpg and contrib/dblink, apparently to avoid session
reconnections. That seems likely to me to be losing test coverage.
Perhaps there is no alternative, but I'd like to have some discussion
around that point as well.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/01/2014 05:10 PM, Tom Lane wrote:
One other thought here: is it actually reasonable to expend a lot of effort
on the Windows case? I'm not aware that people normally expect a Windows
box to have multiple users at all, let alone non-mutually-trusting users.
As Stephen said, it's fairly unusual. There are usually quite a few
roles, but it's rare to have more than one "human" type role connected
to the machine at a given time.
I'd be happy doing nothing in this case, or not very much. e.g. provide
a password but not with great cryptographic strength.
BTW, a different problem with the proposed patch is that it changes
some test cases in ecpg and contrib/dblink, apparently to avoid session
reconnections. That seems likely to me to be losing test coverage.
Perhaps there is no alternative, but I'd like to have some discussion
around that point as well.
Yeah. Assuming we make the changes you're suggesting that should no
longer be necessary, right?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
On 03/01/2014 05:10 PM, Tom Lane wrote:
BTW, a different problem with the proposed patch is that it changes
some test cases in ecpg and contrib/dblink, apparently to avoid session
reconnections. That seems likely to me to be losing test coverage.
Perhaps there is no alternative, but I'd like to have some discussion
around that point as well.
Yeah. Assuming we make the changes you're suggesting that should no
longer be necessary, right?
Not sure. I believe the point of those changes is that the scaffolding
only sets up a password for the original superuser, so that connecting
as anybody else will fail if the test postmaster is configured for
password auth. If so, the only way to avoid doing any work would be
if we don't implement any fix at all for Windows.
Whether or not you're worried about the security of "make check" on
Windows, there are definitely some things to be unhappy about here.
One being that the core regression tests are evidently not testing
connecting as anybody but superuser; and the proposed changes would remove
such testing from contrib and ecpg as well, which is surely not better
from a coverage standpoint. (It's not terribly hard to imagine
permissions bugs that would cause postinit.c to fail for non-superusers.)
Another issue is that (I presume, haven't checked) "make installcheck"
on contrib or ecpg will currently fail against a server that's not
configured for trust auth. Ideally you should be able to do "make
installcheck" against a reasonably-configured server.
I'm not real sure what to do about either of those points, but I am sure
that the proposed patch isn't moving the ball downfield.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Mar 01, 2014 at 05:51:46PM -0500, Andrew Dunstan wrote:
On 03/01/2014 05:10 PM, Tom Lane wrote:
One other thought here: is it actually reasonable to expend a lot of effort
on the Windows case? I'm not aware that people normally expect a Windows
box to have multiple users at all, let alone non-mutually-trusting users.As Stephen said, it's fairly unusual. There are usually quite a few
roles, but it's rare to have more than one "human" type role
connected to the machine at a given time.
I, too, agree it's rare. Rare enough to justify leaving the vulnerability
open on Windows, indefinitely? I'd say not. Windows itself has been pushing
steadily toward better multi-user support over the past 15 years or so.
Releasing software for Windows as though it were a single-user platform is
backwards-looking. We should be a model in this area, not a straggler.
I'd be happy doing nothing in this case, or not very much. e.g.
provide a password but not with great cryptographic strength.
One option that would simplify things is to fix only non-Windows in the back
branches, via socket protection, and fix Windows in HEAD only. We could even
do so by extending HAVE_UNIX_SOCKETS support to Windows through named pipes.
Using weak passwords on Windows alone would not simplify the effort.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Mar 01, 2014 at 09:43:19PM -0500, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
On 03/01/2014 05:10 PM, Tom Lane wrote:
BTW, a different problem with the proposed patch is that it changes
some test cases in ecpg and contrib/dblink, apparently to avoid session
reconnections. That seems likely to me to be losing test coverage.
Perhaps there is no alternative, but I'd like to have some discussion
around that point as well.
connect/test5.pgc has the same number of session reconnections before and
after the patch. The change is to assign passwords to the connection test
accounts and use those passwords during the tests. Test coverage actually
increased there; before, it did not matter whether ecpg conveyed each password
in good order. The dblink change does replace a non-superuser reconnection
with a SET SESSION AUTHORIZATION.
I believe the point of those changes is that the scaffolding
only sets up a password for the original superuser, so that connecting
as anybody else will fail if the test postmaster is configured for
password auth.
Essentially, yes. You can connect as another user if you assign a password;
the ecpg suite does so. (That user had better be unprivileged.) The dblink
change has a second point. Since the dblink_regression_test role has use of
the dblink_connect_u() function, it needs to be treated as a privileged
account. (I'll add a comment about that.)
Another issue is that (I presume, haven't checked) "make installcheck"
on contrib or ecpg will currently fail against a server that's not
configured for trust auth. Ideally you should be able to do "make
installcheck" against a reasonably-configured server.
No, I had verified "make installcheck-world" under md5 auth. The setup I
recommend, which I mentioned in the initial message of this thread, is to put
the same PGPASSFILE in the postmaster environment as you put in the "make
installcheck" environment. (It's contrib/dblink and contrib/postgres_fdw that
would otherwise fail.)
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2 Mar 2014, at 05:20, Noah Misch <noah@leadboat.com> wrote:
On Sat, Mar 01, 2014 at 05:51:46PM -0500, Andrew Dunstan wrote:
On 03/01/2014 05:10 PM, Tom Lane wrote:
One other thought here: is it actually reasonable to expend a lot of effort
on the Windows case? I'm not aware that people normally expect a Windows
box to have multiple users at all, let alone non-mutually-trusting users.As Stephen said, it's fairly unusual. There are usually quite a few
roles, but it's rare to have more than one "human" type role
connected to the machine at a given time.I, too, agree it's rare. Rare enough to justify leaving the vulnerability
open on Windows, indefinitely?
It's not that rare in my experience - certainly there are far more single user installations, but Terminal Server configurations are common for deploying apps "Citrix-style" or VDI. The one and only Windows server maintained by the EDB infrastructure team is a terminal server for example.
I'd say not. Windows itself has been pushing
steadily toward better multi-user support over the past 15 years or so.
Releasing software for Windows as though it were a single-user platform is
backwards-looking. We should be a model in this area, not a straggler.
Definitely.
I'd be happy doing nothing in this case, or not very much. e.g.
provide a password but not with great cryptographic strength.One option that would simplify things is to fix only non-Windows in the back
branches, via socket protection, and fix Windows in HEAD only. We could even
do so by extending HAVE_UNIX_SOCKETS support to Windows through named pipes.Using weak passwords on Windows alone would not simplify the effort.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Mar 2, 2014 at 6:20 AM, Noah Misch <noah@leadboat.com> wrote:
On Sat, Mar 01, 2014 at 05:51:46PM -0500, Andrew Dunstan wrote:
On 03/01/2014 05:10 PM, Tom Lane wrote:
One other thought here: is it actually reasonable to expend a lot of
effort
on the Windows case? I'm not aware that people normally expect a
Windows
box to have multiple users at all, let alone non-mutually-trusting
users.
As Stephen said, it's fairly unusual. There are usually quite a few
roles, but it's rare to have more than one "human" type role
connected to the machine at a given time.I, too, agree it's rare. Rare enough to justify leaving the vulnerability
open on Windows, indefinitely? I'd say not. Windows itself has been
pushing
steadily toward better multi-user support over the past 15 years or so.
Releasing software for Windows as though it were a single-user platform is
backwards-looking. We should be a model in this area, not a straggler.
Terminal Services have definitely become more common over time, but with
faster and cheaper virtualization, a lot of people have switched to that
instead, which would remove the problem of course.
I wonder how common it actually is, though, to *build postgres* on a
terminal services machine with other users on it...
Not saying we can't ignore it, and I gree that we should not be a straggler
on this, so doing a proper fix wwould definitely be the better.
I'd be happy doing nothing in this case, or not very much. e.g.
provide a password but not with great cryptographic strength.
One option that would simplify things is to fix only non-Windows in the
back
branches, via socket protection, and fix Windows in HEAD only. We could
even
do so by extending HAVE_UNIX_SOCKETS support to Windows through named
pipes.
That could certainly be a useful feature of it's own. But as you say,
non-backpatchable.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
* Dave Page (dpage@pgadmin.org) wrote:
It's not that rare in my experience - certainly there are far more single user installations, but Terminal Server configurations are common for deploying apps "Citrix-style" or VDI. The one and only Windows server maintained by the EDB infrastructure team is a terminal server for example.
Sure- but do you have a full build environment there for building PG?
That's really what I'm referring to as being relatively rare. I'm very
familiar with terminal servers, but those are almost always used for
getting access to IE or other corporate dependencies, or for coming in
from remote, or running Windows-only applications. We've got a terminal
server at my current job, and I ran a whole slew of them at my last job
and in neither case did we have development tools installed.
Thanks,
Stephen
Noah Misch <noah@leadboat.com> writes:
One option that would simplify things is to fix only non-Windows in the back
branches, via socket protection, and fix Windows in HEAD only. We could even
do so by extending HAVE_UNIX_SOCKETS support to Windows through named pipes.
+1 for that solution, if it's not an unreasonable amount of work to add
named-pipe sockets in Windows. That would offer a feature to Windows
users that they didn't have before, ie the ability to restrict connections
based on filesystem permissions; so it seems useful quite aside from any
"make check" considerations.
There's an independent question of whether the regression tests will work
for "make installcheck" against a server that's not set up for trust auth.
I'm inclined to think that we can leave it to the user to generate
appropriate passwords if he's using password auth, but don't we still
need some test procedure adjustments?
Also, to what extent does any of this affect buildfarm animals? Whatever
we do for "make check" will presumably make those tests safe for them,
but how are the postmasters they test under "make installcheck" set up?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 02/03/2014 15:30, Magnus Hagander wrote:
Terminal Services have definitely become more common over time, but
with faster and cheaper virtualization, a lot of people have switched
to that instead, which would remove the problem of course.I wonder how common it actually is, though, to *build postgres* on a
terminal services machine with other users on it...
Well, the banks I've contracted at recently are all rather keen on
virtual desktops for developers, and some of those are terminal
services. We're a headache, and packaging up all the things we need is
a pain, so there is some mileage in buying grunty servers and doing
specific installs that are then shared, rather than making an MSI
generally available.
Also I have experience of being given accounts for jenkins etc that are
essentially terminal services logins, and having these things unable to
maintain a software stack can effectively disqualify tech we would
otherwise use.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/02/2014 01:27 PM, Tom Lane wrote:
Also, to what extent does any of this affect buildfarm animals? Whatever
we do for "make check" will presumably make those tests safe for them,
but how are the postmasters they test under "make installcheck" set up?
Nothing special.
"bin/initdb" -U buildfarm --locale=$locale data-$locale
...
"bin/pg_ctl" -D data-$locale -l logfile -w start
We have wide control over what's done, just let me know what's wanted.
For example, it would be pretty simple to make it use a non-standard
socket directory and turn tcp connections off on Unix, or to set up
password auth for that matter, assuming we already have a strong password.
I generally assume that people aren't running buildfarm animals on
general purpose multi-user machines, but it might be as well to take
precautions.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* james (james@mansionfamily.plus.com) wrote:
Well, the banks I've contracted at recently are all rather keen on
virtual desktops for developers, and some of those are terminal
services. We're a headache, and packaging up all the things we need
is a pain, so there is some mileage in buying grunty servers and
doing specific installs that are then shared, rather than making an
MSI generally available.Also I have experience of being given accounts for jenkins etc that
are essentially terminal services logins, and having these things
unable to maintain a software stack can effectively disqualify tech
we would otherwise use.
And what are the feelings security on these multi-user development
environments? Is everyone on them trusted users, or are there
untrusted / general accounts?
The issue here is about how much effort to go to in order to secure the
PostgreSQL system that is started up to do the regression tests. It's
already set up to only listen on localhost and will run with only the
privileges of the user running the tests. The concern is that another
user on the same system could gain access to the account which is
running the 'make check' by connecting over localhost to the PostgreSQL
instance and being superuser there, which would allow executing
commands, etc, as that other user (eg: with COPY PIPE).
THanks,
Stephen
