public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 08/19] vcregress: add alltaptests 2+ messages / 2 participants [nested] [flat]
* [PATCH 08/19] vcregress: add alltaptests @ 2022-02-25 23:00 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Justin Pryzby @ 2022-02-25 23:00 UTC (permalink / raw) https://www.postgresql.org/message-id/[email protected] https://www.postgresql.org/message-id/flat/[email protected] In passing, document taptest PROVE_FLAGS ci-os-only: windows See also: d835dd6685246f0737ca42ab68242210681bb220 13d856e177e69083f543d6383eeda9e12ce3c55c fed6df486dca1b9e53d3f560031b9a236c99f4bb --- .cirrus.yml | 10 ++------- src/tools/msvc/vcregress.pl | 43 +++++++++++++++++++++++++++++++++---- 2 files changed, 41 insertions(+), 12 deletions(-) diff --git a/.cirrus.yml b/.cirrus.yml index f2bb05266cc..ea1f493923a 100644 --- a/.cirrus.yml +++ b/.cirrus.yml @@ -437,14 +437,8 @@ task: test_ssl_script: | set with_ssl=openssl %T_C% perl src/tools/msvc/vcregress.pl taptest ./src/test/ssl/ - test_subscription_script: | - %T_C% perl src/tools/msvc/vcregress.pl taptest ./src/test/subscription/ - test_authentication_script: | - %T_C% perl src/tools/msvc/vcregress.pl taptest ./src/test/authentication/ - test_recovery_script: | - %T_C% perl src/tools/msvc/vcregress.pl recoverycheck - test_bin_script: | - %T_C% perl src/tools/msvc/vcregress.pl bincheck + test_tap_script: | + %T_C% perl src/tools/msvc/vcregress.pl alltaptests test_ecpg_script: | rem tries to build additional stuff vcvarsall x64 diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl index 54c31b0e14f..1b1387acac0 100644 --- a/src/tools/msvc/vcregress.pl +++ b/src/tools/msvc/vcregress.pl @@ -51,7 +51,7 @@ if (-e "src/tools/msvc/buildenv.pl") my $what = shift || ""; if ($what =~ - /^(check|installcheck|plcheck|contribcheck|modulescheck|ecpgcheck|isolationcheck|upgradecheck|bincheck|recoverycheck|taptest)$/i + /^(check|installcheck|plcheck|contribcheck|modulescheck|ecpgcheck|isolationcheck|upgradecheck|bincheck|recoverycheck|taptest|alltaptests)$/i ) { $what = uc $what; @@ -109,6 +109,7 @@ my %command = ( BINCHECK => \&bincheck, RECOVERYCHECK => \&recoverycheck, UPGRADECHECK => \&upgradecheck, # no-op + ALLTAPTESTS => \&alltaptests, TAPTEST => \&taptest,); my $proc = $command{$what}; @@ -291,6 +292,9 @@ sub tap_check $ENV{PG_REGRESS} = "$topdir/$Config/pg_regress/pg_regress"; $ENV{REGRESS_SHLIB} = "$topdir/src/test/regress/regress.dll"; + print "============================================================\n"; + print "Checking $dir: @args\n"; + rmtree('tmp_check'); system(@args); my $status = $? >> 8; @@ -305,8 +309,7 @@ sub bincheck my $mstat = 0; - # Find out all the existing TAP tests by looking for t/ directories - # in the tree. + # Find the TAP tests by looking for t/ directories my @bin_dirs = glob("$topdir/src/bin/*"); # Process each test @@ -321,6 +324,36 @@ sub bincheck return; } +sub alltaptests +{ + InstallTemp(); + + my $mstat = 0; + + # Find out all the existing TAP tests by looking for t/ directories + # in the tree. + my @tap_dirs = (); + my @top_dir = ($topdir); + File::Find::find( + { wanted => sub { + /^t\z/s + && $File::Find::name !~ /\/(kerberos|ldap|ssl|ssl_passphrase_callback)\// # opt-in + && push(@tap_dirs, $File::Find::name); + } + }, + @top_dir); + + # Process each test + foreach my $test_path (@tap_dirs) + { + my $dir = dirname($test_path); + my $status = tap_check($dir); + $mstat ||= $status; + } + exit $mstat if $mstat; + return; +} + sub taptest { my $dir = shift; @@ -671,6 +704,7 @@ sub usage print STDERR "Usage: vcregress.pl <mode> [<arg>]\n\n", "Options for <mode>:\n", + " alltaptests run all tap tests (except kerberos, ldap, ssl, ssl_passphrase_callback)\n", " bincheck run tests of utilities in src/bin/\n", " check deploy instance and run regression tests on it\n", " contribcheck run tests of modules in contrib/\n", @@ -688,6 +722,7 @@ sub usage "\nOptions for <arg>: (used by contribcheck and modulescheck)\n", " install also run tests which require a new instance\n", "\nOption for <arg>: for taptest\n", - " TEST_DIR (required) directory where tests reside\n"; + " TEST_DIR (required) directory where tests reside\n", + " PROVE_FLAGS flags to pass to prove\n"; exit(1); } -- 2.17.1 --Sw7tCqrGA+HQ0/zt Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0009-tmp-run-tap-tests-first.patch" ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: [PATCH] New predefined role pg_manage_extensions @ 2024-11-18 06:30 Kirill Reshke <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Kirill Reshke @ 2024-11-18 06:30 UTC (permalink / raw) To: Michael Banck <[email protected]>; +Cc: Jelte Fennema-Nio <[email protected]>; PostgreSQL Hackers <[email protected]> On Mon, 18 Nov 2024 at 11:26, Kirill Reshke <[email protected]> wrote: > > On Fri, 1 Nov 2024 at 02:47, Michael Banck <[email protected]> wrote: > > > > Hi, > > > > Even though there has not been a lot of discussion on this, here is a > > rebased patch. I have also added it to the upcoming commitfest. > > > Hi! > > > + <literal>pg_manage_extensions</literal> allows creating, removing or > > + updating extensions, even if the extensions are untrusted or the user is > > + not the database owner. > > Users are not required to be a database owner to create extensions. > They are required to have CREATE priv on database. > > > On Sat, Jan 13, 2024 at 09:20:40AM +0100, Michael Banck wrote: > > > On Fri, Jan 12, 2024 at 04:13:27PM +0100, Jelte Fennema-Nio wrote: > > > > But I'm not sure that such a pg_manage_extensions role would have any > > > > fewer permissions than superuser in practice. > > > > > > Note that just being able to create an extension does not give blanket > > > permission to use it. I did a few checks with things I thought might be > > > problematic like adminpack or plpython3u, and a pg_manage_extensions > > > user is not allowed to call those functions or use the untrusted > > > language. > > > > > > > Afaik many extensions that are not marked as trusted, are not trusted > > > > because they would allow fairly trivial privilege escalation to > > > > superuser if they were. > > > > > > While that might be true (or we err on the side of caution), I thought > > > the rationale was more that they either disclose more information about > > > the database server than we want to disclose to ordinary users, or that > > > they allow access to the file system etc. > > Extension installation script can execute arbitrary code with > superuser privilege if markled trusted. > > Take this example > > ``` > > reshke@yezzey-cbdb:~/postgres/contrib/fooe$ cat fooe.control > # fooe extnesion > comment = 'foo bar baz' > default_version = '1.0' > module_pathname = '$libdir/fooe' > relocatable = true > trusted = true > reshke@yezzey-cbdb:~/postgres/contrib/fooe$ cat fooe--1.0.sql > /* contrib/fooe/fooe--1.0.sql */ > > -- complain if script is sourced in psql, rather than via CREATE EXTENSION > \echo Use "CREATE EXTENSION fooe" to load this file. \quit > > > CREATE ROLE pwned WITH LOGIN SUPERUSER; > > reshke@yezzey-cbdb:~/postgres/contrib/fooe$ ../../pgbin/bin/psql -d db2 > db2=# create role user_no_sup with login; > CREATE ROLE > db2=# ^C > \q > I'm sorry, the example is incomplete. Here is missing command: db2=# grant create on database db2 to user_no_sup ; GRANT > reshke@yezzey-cbdb:~/postgres/contrib/fooe$ ../../pgbin/bin/psql -U > user_no_sup -d db2 > psql (18devel) > Type "help" for help. > > db2=> create extension fooe ; > CREATE EXTENSION > db2=> \du+ > List of roles > Role name | Attributes > | Description > -------------+------------------------------------------------------------+------------- > pwned | Superuser | > reshke | Superuser, Create role, Create DB, Replication, Bypass RLS | > user1 | | > user2 | | > user_no_sup | | > > db2=> ^C > > ``` > > > > > I think if we have extensions in contrib that trivially allow > > > non-superusers to become superusers just by being installed, that should > > > be a bug and be fixed by making it impossible for ordinary users to > > > use those extensions without being granted some access to them in > > > addition. > > > > > > After all, socially engineering a DBA into installing an extension due > > > to user demand would be a thing anyway (even if most DBAs might reject > > > it) and at least DBAs should be aware of the specific risks of a > > > particular extension probably? > > > > > > Michael > > > In general, this concept is rather dubious. Why should we have such a > dangerous pre-defined role? I would prefer to have complete control > over what gets installed in the database if I were a superuser. > Additionally, if a dangerous extension is inadvertently or otherwise > loaded on the host, I never want a normal user to run code with > superuser privileges. > > For a thorough understanding of the current situation and the > rationale behind the design, you can read this[1] discussion. > > > [1] https://www.postgresql.org/message-id/5889.1566415762%40sss.pgh.pa.us > > -- > Best regards, > Kirill Reshke -- Best regards, Kirill Reshke ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-11-18 06:30 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2022-02-25 23:00 [PATCH 08/19] vcregress: add alltaptests Justin Pryzby <[email protected]> 2024-11-18 06:30 Re: [PATCH] New predefined role pg_manage_extensions Kirill Reshke <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox