Do shell script with administrator privileges bug in Sonoma and Sequoia?

Hi,

Continuing the discussion from Problem with do shell script and chflags command - I am under the impression that there is a major bug:

Try this (I am sorry but I can offer only a script template - and be assured that I checked and double checked folder and bundle permissions, as well as user name and password on two (Intel-)Macs and the mentioned OSes and that I am aware of the dangers of rm -rf) replacing XXX.app by any application bundle (could be any file though) at the given location:

The following does not work - “operation not permitted”:

do shell script "rm -rf '/Users/[myAccount]/Downloads/XXX.app'" with administrator privileges 
-- same with hardcoded username and PW

This one, however, does without a hitch:

do shell script "rm -rf '/Users/[myAccount]/Downloads/XXX.app'"

Both of the following spectacularly work, too:

do shell script "rm -rf '/Applications/XXX.app'" with administrator privileges

and

do shell script "rm -rf '/Applications/XXX.app'"

I can run
rm -rf '/Users/[myAccount]/Downloads/XXX.app'"

or

sudo rm -rf '/Users/[myAccount]/Downloads/XXX.app'"

in a terminal and both work.

I can select the app in the Finder and press cmd-backspace and it gets moved to the trash etc. etc.

I experimented with a slew of TCC privileges like full disk acces, application administration etc. etc., some of them or certain combinations of them making FastScript, or Script Debugger crash or the applet bringing up incomprehensible and unrelated error messages (about a window in a previous launch I tried to open and if I’d like to try again). I exported the script as a read-only bundle from ScriptDebugger. To no avail.

So something seems to be fundamentally wrong here, or I am doing something fundamentally wrong.

I’d appreciate any pointers. Thank you!

Have you tried passing the user name and password parameters when using ‘with administrator privileges’?

Yes. In my first code block you have to scroll to the right (sadly) to see

Added a return now so that it becomes more visible.

Thanks!

The access privileges of Users/[myAccount]/Downloads are: Only myAccount can read and write, nobody else, system (called by with administrator privileges) doesn’t have access.

Yes, you (myAccount, the current user) do have access.

/Applications on the other hand has access privileges system and admin accounts can read and write.

with administrator privileges gains the rights of the system account, and the latter uses the admin rights of myAccount.

OK. But I am the admin and I am running this from the admin account.
So I understand why it works without admin privileges but don’t understand why it does not when using them.
Furthermore, I am registered as admin for the applications folder (besides system), and I can delete with and without admin privileges.
Sounds contradictory to me.

admin privileges is the AppleScript equivalent to sudo, it gains system (the root user) privileges. In an admin account you don’t need any additional privileges to access admin rights.

OK - but since system is the R/W-Owner it should work, shouldn’t it? Certainly worked on older systems. Don’t remember, but I used Mojave and Monterey before Sonoma and Sequoia.

In /Applications, but not in Downloads.

Ah, OK, of course. Now even I got it.
So how to come up with a script working under all these circumstances?
Pseudo code:

try
do without admin privileges
on error
do the same with admin privileges
end

Or the like?

You could check the privileges/ownership in Finder or with a shell command.

Pretty much just like you tried.

try
    do shell script "rm -rf /path/to/some/resource"
on error
    do shell script "rm -rf /path/to/some/resource" with administrator privileges username...password...blahblahblah
end try 

granted this will trigger on any error, not just a permission error, but it may be enough.