MDEV-37948 ALTER TABLE TRUNCATE PARTITION requires only DROP privilege

[FarihaIS]

Description

ALTER TABLE ... TRUNCATE PARTITION only checks for DROP privilege, which is inconsistent with the expectation that ALTER TABLE statements should require ALTER privilege. This creates a privilege gap since users with only DROP can truncate partitions without ALTER rights.

Add ALTER privilege check to TRUNCATE PARTITION, allowing either DROP or ALTER privilege for backwards compatibility. This matches the intended behavior while preserving existing functionality.

Release Notes

N/A

How can this PR be tested?

Execute the main.partition_grant test in mysql-test-run. This commit adds a test in partition_grant.test.

Before the fix

A user with only ALTER privilege cannot truncate partitions (only DROP works):

main.partition_grant                     [ fail ]
        Test ended at 2026-02-25 19:04:08

CURRENT_TEST: main.partition_grant
mysqltest: At line 118: query 'ALTER TABLE t1 TRUNCATE PARTITION p2' failed: ER_TABLEACCESS_DENIED_ERROR (1142): DROP command denied to user 'mysqltest_2'@'localhost' for table `mysqltest_2`.`t1`

The result from queries just before the failure was:
< snip >
CREATE USER mysqltest_2@localhost;
# Test with only DROP privilege (should succeed)
GRANT DROP ON mysqltest_2.* TO mysqltest_2@localhost;
connect  conn_drop,localhost,mysqltest_2,,mysqltest_2;
SHOW GRANTS FOR CURRENT_USER;
Grants for mysqltest_2@localhost
GRANT USAGE ON *.* TO `mysqltest_2`@`localhost`
GRANT DROP ON `mysqltest_2`.* TO `mysqltest_2`@`localhost`
ALTER TABLE t1 TRUNCATE PARTITION p1;
disconnect conn_drop;
connection default;
REVOKE DROP ON mysqltest_2.* FROM mysqltest_2@localhost;
# Test with only ALTER privilege (should succeed)
GRANT ALTER ON mysqltest_2.* TO mysqltest_2@localhost;
connect  conn_alter,localhost,mysqltest_2,,mysqltest_2;
SHOW GRANTS FOR CURRENT_USER;
Grants for mysqltest_2@localhost
GRANT USAGE ON *.* TO `mysqltest_2`@`localhost`
GRANT ALTER ON `mysqltest_2`.* TO `mysqltest_2`@`localhost`
ALTER TABLE t1 TRUNCATE PARTITION p2;

After the fix

A user needs either ALTER or DROP privilege to truncate partitions. Users with neither privilege are denied:

main.partition_grant                     [ pass ]    108

Basing the PR against the correct MariaDB version

• This is a bug fix, and the PR is based against the branch 10.6.

Copyright

All new code of the whole pull request, including one or several files that are either new files or modified ones, are contributed under the BSD-new license. I am contributing on behalf of my employer Amazon Web Services, Inc.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[svoj]

LGTM

[gkodinov]

Thank you for your contribution. This is a preliminary review.

First things first: PLEASE sign the CLA. Click on the button saying "CLA not signed yet" and make sure it is signed.

Next, rebase your diff to the 10.6 branch. This is a bug, not a feature. And it needs to be fixed as such.

Then please take a look at the comments below and (at least) fix the tests and the check to be an OR check.

[gkodinov]

Typically mysqltest would continue right after getting the OK from the server. The server sends the OK as early as humanely possible so that it doesn't slow the client down. But the session can linger on for some time until the server eventually clears it up at the background. This can account for nasty sporadic failures in testing.
This is why, as a rule of thumb, we always source include/count_sessions.inc at the start of a test that executes connect() and then, when cleaning up, we source include/wait_until_count_sessions.inc to ensure that all the sessions created by the test are properly disposed of before we continue.

Please use the above .inc files as described. Plenty of examples of that throughout the test suite to copy from.

[svoj]

No, please don't. This concept has proven to be broken, we mustn't spread it further.

[gkodinov]

@svoj, would you elaborate, please?

[svoj]

Onee problem is that count_sessions.inc itself can be affected by such lingering connections. Be that connections from preceding tests or mysqltest utility connections. Or even valid connections that were created before count_sessions.inc was included and then went away in the middle of the test.

The most common case that I observed was lingering mysqltest "check testcase" connection making count_sessions.inc record value of "2" instead of expected "1". Which makes wait_until_count_sessions.inc in preceding tests meaningless.

Instead we either filter out unwanted connections in affected tests by adding WHERE clause or add let $count_sessions= 1; and then wait_until_count_sessions.inc when it is impossible (like SHOW PROCESSLIST).

[gkodinov]

true. But even in that case it won't hurt I guess. It'd be a no-op at best, right? And it still has the potential to improve the stability of the test in case count_sessions.inc worked as expected.
So, in my book, there's still some benefit in having these. And it might even increase with time if we fix count_sesisons to be more robust. But this will happen only if we keep including these.

[svoj]

Sorry, but this sounds like "false feeling of safety" in OCD terms. :)

It is just a garbage, it doesn't bring any value.

[gkodinov]

So you do not agree that there's added value in having these in case count_sessions.inc works? What makes you think that? It will work most of the times.

[svoj]

Correct, it doesn't bring any value. Because it was decided to move from concept that "works most of the times" to something that "just works". It was mostly implemented by #4339, #4382, #4383, #4401, #4409, #4414, #4421, #4456, #4501, #4502, #4511, #4524, #4526, #4527, #4528, #4530, #4531, #4532.

[gkodinov]

let's leave this for the final reviewer then. It looks like you and me disagree on the topic.

[FarihaIS]

First things first: PLEASE sign the CLA. Click on the button saying "CLA not signed yet" and make sure it is signed.

We are currently reviewing whether we can sign the CLA bot as per our internal contribution procedures, so I will hold off on this for a moment.

Next, rebase your diff to the 10.6 branch. This is a bug, not a feature. And it needs to be fixed as such.

Done, the PR is now targeting the 10.6 branch. I have also updated the PR description to reflect this.

Then please take a look at the comments below and (at least) fix the tests and the check to be an OR check.

I believe all the comments (except the one that reads like below) have been addressed. I fixed the tests and also modified the check to be an OR check. Do you think the diff looks good now? If not, please let me know and I can make further changes, thank you!

My 2 cents on the subject (please ignore until the final review):

[vuvova]

First things first: PLEASE sign the CLA. Click on the button saying "CLA not signed yet" and make sure it is signed.

We are currently reviewing whether we can sign the CLA bot as per our internal contribution procedures, so I will hold off on this for a moment.

@FarihaIS, don't worry about CLA, you do not need to sign it. The rule always was CLA or BSD You wrote above that this PR is contributed under BSD (as AWS contributions always are), this is sufficient. Thank you!

[gkodinov]

LGTM. thank you for working on this. Please stand by for the final review.