Until a few weeks ago I was using a MacBook running Mojave. Since then I’ve been using another MacBook running Big Sur and I’m seeing weird things.

I have a couple of bash scripts that ran perfectly on the Mojave Mac, but not on my Big Sur Mac. Yesterday I took some time to discover why, and it’s this: wildcards don’t work in ~/.Trash. Hard to believe, but here’s my evidence:

bash{1}> cd ~/.Trash
/Users/Doug/.Trash
bash{2}> ls new_clippings_copy10
new_clippings_copy10
bash{3}> ls new_clippings*
ls: new_clippings*: No such file or directory
bash{4}> ls -a
ls: .: Operation not permitted
bash{5}>

So wildcards don’t work in ~/.Trash. WHY???

BTW – I see the same weirdness in ~/Downloads so it’s been equally damaged by Tim Cook.

Does anyone have an explanation for this weird behavior?

Directory permissions would be my guess. Observe:

> mkdir Foo
> ls -ld Foo
drwxr-x--- 2 username somegroup 4096 Apr 18 12:23 Foo
> cd Foo
> echo bar >baz
> ls baz
baz
> ls ba*
baz
> ls -a
.  ..  baz
> chmod a-r .
> ls baz
baz
> ls ba*
ls: cannot access ba*: No such file or directory
> ls -a
ls: cannot open directory .: Permission denied
> cd ..
> ls -ld Foo
d-wx--x--- 2 username somegroup 4096 Apr 18 12:25 Foo
>

According to this, terminal does not have full permissions in .Trash. Check this out:
https://apple.stackexchange.co...ration-not-permitted

Interesting, never noticed. A bare 'ls' fails as does 'ls -a', nor does stuff like 'echo *'. Same behavior in csh in Monterey indicating that this is likely an apfs thing rather than the shell. Looking at the file flags associated with ~/.Trash and files within it reveals little of the whys, the man page for ls is not particularly helpful, although it reveals the existence of a -@ flag that shows that files created within .Trash get tagged with "extended attributes" (but does not indicate what these might be). Might be interesting to see what things look like with the root fs being of a different type.

Undoubtedly, this was implemented to prevent detrimental actions in certain "sensitive" directories. For "security" you know.

Other weirdness in recent versions of macOS include the non-traditional loss of inheritance in file sharing where exporting a directory also exports the entire tree under that mount point. Share your $HOME and ~/Downloads should be shared too, but no longer. It may be that disallowing wildcards has this unexpected effect on smbd since it can't enumerate the directory's contents.

OK, so macOS isn't unix. I don't recall Apple ever promising that it would be. Somewhere in either a macOS developer's forum or freebsd-dev a dedicated explorer may find discussion of this change, but it strikes me as very rude to make a change of this nature without reporting it (loudly) to the community of users.

Thread title reading 101: I failed

Skimming threads, see this one and I click on it to read about the weird unisex goings on in Big Sur.

Get 10 words into the first sentence, think "What the hell?", read the thread title again. Call myself an idiot.

Leaving now, carry on.

quote:

Originally posted by architect:
... it reveals the existence of a -@ flag that shows that files created within .Trash get tagged with "extended attributes" (but does not indicate what these might be).

Does the system have getfacl and setfacl, the POSIX extensions for File Access Control Lists?

Though I"m not familiar with the "-@" flag. That's a new one on me.

Thanks to all.

I used the guidance in xd45man’s link:
Security & Privacy > Full Disk Access (scroll down) > Terminal.

Now wildcards work in ~/.Trash and ~/Downloads. I am soooo happy about that! My scripts are working again. My thanks to xd45man.

This message has been edited. Last edited by: Pipe Smoker,

quote:

Originally posted by architect:
<snip>
Undoubtedly, this was implemented to prevent detrimental actions in certain "sensitive" directories. For "security" you know.
<snip>

Only weird Tim Cook could come to the conclusion that Trash is the most sensitive Mac directory. And that disabling wildcards is a good way to protect sensitive directories.

quote:

Originally posted by Pipe Smoker:
And that disabling wildcards is a good way to protect sensitive directories.

"Security by obscurity," while not the best defense in the world, is a valid mechanism.

E.g.: To prevent abuse, FTP on my server has a separate "incoming" directory, which is the only directory to which unauthenticated logins can upload. Among other anti-abuse measures: The contents, if any, cannot be listed via FTP.

quote:

Originally posted by Pipe Smoker:

quote:

Originally posted by architect:
<snip>
Undoubtedly, this was implemented to prevent detrimental actions in certain "sensitive" directories. For "security" you know.
<snip>

Only weird Tim Cook could come to the conclusion that Trash is the most sensitive Mac directory. And that disabling wildcards is a good way to protect sensitive directories.

It isn't (just) wildcards that are disabled, it is general directory enumeration. I suspect there are other file system (or "extended attributes") prohibitions as well, but there does not seem to be a utility, either GUI or CLI, to view or configure these atomically. The "Allow Full Access" option In Security Preferences suggests only GUI applications, and does not seem to support daemons and command-line tools (although running a shell in Terminal gets you part of the way there). More weirdness, the "extended attributes" appear to be applied only to the contents of the directory, not the directory itself, IOW not initiated by inheritance. All (apparently) to hinder temporary file name guessing/discovery by malware! Somebody tell Apple that "security by obscurity is no security at all."

WRT ensigmatics query about Posix ACLs, yes, recent macOS and the apfs support these too, without the sefacl and getfacl CLI utilities (but there is an "-O" switch to ls that does the expected thing. The "extended attributes" is yet another layer that appears to do something like ACLs, albeit in a different non-standards-compliant way.

Another gripe: sudo appears to ignore the sudoers file (or at least its contents).

Is Apple going all Microsoft on us?

quote:

Originally posted by architect:
The "extended attributes" is yet another layer that appears to do something like ACLs, albeit in a different non-standards-compliant way.

Another gripe: sudo appears to ignore the sudoers file (or at least its contents).

Wonderful

quote:

Originally posted by architect:
Is Apple going all Microsoft on us?

I don't know, but, the more I hear about recent versions of MacOS, the more inclined I am to just stick with Linux.

We were this >< close to acquiring a pair of Mac Minis when Apple announced their intention to add spyware to iOS, iPadOS, and MacOS. That brought those plans to a screeching halt. Now, even if they do ever announce they've permanently ended those plans, we're unlikely to buy them.

 
/usr/bin/xattr deals with extended attributes. You can use the -l switch to view them, and the -d switch to delete the.

data point only

Yesterday, my MacBook Pro (2022) black screened coming off external monitor HDMI and external power (going mobile to the other room for a Zoom). Took an off button hold of death to choke it into rebooting. Never happened before. Maybe coincidence. But I did just take that last update the other day.

quote:

Originally posted by henryaz:
 
/usr/bin/xattr deals with extended attributes. You can use the -l switch to view them, and the -d switch to delete the.

Thanks! I don't know why 'apropos attributes' didn't find this when I looked, I probably fat-fingered the argument.

Ensigmatic, don't give up on those Mac Mini's, I have a client who has maybe 30 of them placed in data centers around the world, and they are remarkably easy to manage, expecially given that the local support folks have very variable skill sets, a lot easier to find a "remote Mac guy" than a "remote Linux guy," (at least one that has the maturity to not do something irreversible out of sheer curiosity and ignorance, IOW one that can be trusted with root).

quote:

Originally posted by architect:
Ensigmatic, don't give up on those Mac Mini's, ... and they are remarkably easy to manage, ...

Like I said: It's not just this.

Mainly it was this:

A while back Apple announced they were going to embed CSAM (Child Sexual Abuse Material) scanners into iOS, iPadOS, and, astonishingly, MacOS.

While I certainly don't support child abuse or the promulgation of child porn, I'm not going to have spyware, no matter how well-intentioned, on my property.

Apple received so much push-back over this ill-conceived idea (it was soundly thrashed by every network security, privacy advocate, and civil libertarian individual and organization on the planet) they "suspended" the project for "further review."

(I suspect what really got their attention was their sales projections even took a hit and, IIRC, their stock even took a minor hit.)

In the meantime researchers discovered some of the code to support this abomination was already in iOS/iPadOS 15.x. Naturally, researchers took to beating it up. Unsurprisingly: It turned out to be subject to false positives.

Despite all this, they have yet to have definitively cancelled the program. Until and unless they do: The ensigmatic household won't be acquiring any additional Apple hardware except possibly an additional Apple TV.

quote:

Originally posted by architect:

quote:

Originally posted by henryaz:
 
/usr/bin/xattr deals with extended attributes. You can use the -l switch to view them, and the -d switch to delete the.

Thanks! I don't know why 'apropos attributes' didn't find this when I looked

Actually apropos does find it with your command. It is just buried in a voluminous output.

apropos attributes |grep xattr

Blocking fishing expeditions into someone's Trash is not a bad security feature. Many things that we Delete to avoid incrimination (Domestic or otherwise) could become embarrassing if the wrong party (Or agency) found them. Cook's company is just tightening up against the fight with the feds.

quote:

Originally posted by architect:
<snip>
Another gripe: sudo appears to ignore the sudoers file (or at least its contents).
<snip>

Interesting. Several weeks ago an Apple iCloud FU deleted every user-created file on my MacBook:

https://sigforum.com/eve/forum...130059994#5130059994

I hate Tim (The Bean Counter) Cook.

After MUCH frustration I think I’m fully recovered except for one thing: my finely crafted sudoers file is still missing. It appears that Time Machine wasn’t backing up /etc/sudoers. If I “Enter Time Machinne”, I’ve not been able to position it at /etc. Is there a way?

So currently I can’t sudo at all, even in my admin account (recreated after the iCloud FU). But if, as you say, current macOS ignores the content of the sudoers file, then no one else can sudo either, so I’m no worse off than others despite the loss of my sudoers file.

quote:

Originally posted by Pipe Smoker:

quote:

Originally posted by architect:
<snip>
Another gripe: sudo appears to ignore the sudoers file (or at least its contents).
<snip>

Interesting. Several weeks ago an Apple iCloud FU deleted every user-created file on my MacBook:

https://sigforum.com/eve/forum...130059994#5130059994

I hate Tim (The Bean Counter) Cook.

After MUCH frustration I think I’m fully recovered except for one thing: my finely crafted sudoers file is still missing. It appears that Time Machine wasn’t backing up /etc/sudoers. If I “Enter Time Machinne”, I’ve not been able to position it at /etc. Is there a way?

So currently I can’t sudo at all, even in my admin account (recreated after the iCloud FU). But if, as you say, current macOS ignores the content of the sudoers file, then no one else can sudo either, so I’m no worse off than others despite the loss of my sudoers file.

Sudo should still work without a sudoers, just does the defaults ("admin" user only, enter password for every exercise of the command).

Time Machine does appear to be screwy, on Monterey all I get is a blank screen, not the traditional "aged" Finder window. This is what has long happened when accessing TM on a Mac that you are Remote Desktop'd to, back to at least Snow Leopard. I think having two monitors is what is confusing TM.

Having a backup isn't much good when you can't restore. Prob. works in single-user/recovery mode so all is not lost. But adopting a different b/u strategy might give more confidence.

PipeS, you might try accessing /etc with tmutil(8). Also, remember that macOS symlinks /etc to /private/etc. When looking at a b/u on my TM disk in Finder, I can see a /private/etc/sudoers file under the backup directory. One other thing to try if you are inclined, /etc/sudoers.d/ is a way (according to the man page) to add directives without touching the sudoers file.

^^^^^^^^
Thanks architect. I’ll try some of your tips. One problem is that after the iCloud disaster, part of which was that I couldn’t login to my existing admin account, the genius created a new admin account for me with a different name. And my sudoers file doesn’t recognize that name.