Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Search | Test
Home » Learning Curve

A Tale of Woe III

There's a rumour about - again.


This is a tale of woe. And of panic. And of helpful people flailing about in the darkness with NFC. It's a tale of despair but also a tale of hope.

When historians refer back to this incident they'll likely call it 'The 2 May Incident'. 2 May is when Kyle aka drumnkyle got into trouble with Apple's trash directory. With only one hour thirty nine minutes left to the day disaster struck. And oddly enough it was Adobe products striking.

So what happened to Kyle?

That's impossible to know with full certainty without having a full listing of his ~/.Trash directory, but a number of things nevertheless seem certain.

  • sudo rm -fr $HOME/.Trash is overkill anyway. Far better to write sudo rm -fr ~/.Trash.
  • But that still obliterates the trash directory itself. [And the system is kind enough to recreate it at next login.]
  • sudo rm -rf /Users/Kyle/.Trash/* won't work if there are dotted files in those directories. [Remember Kyle repeatedly got 'directory not empty' back when he tried to empty the trash.]
  • But dotted files don't have to be the only reason Kyle couldn't empty the trash.
  • Even if you have files owned by root in the trash you might be able to delete them.
  • But even if you only have your own files in the trash you might not be able to delete them.
  • You can delete a file owned by root at any time if you have write permissions on the parent directory.
  • You cannot delete a file no matter if it's yours if you don't have write permissions on the parent directory.
  • To get things this screwed up Kyle would have had to give away his password.

The last point is very crucial: there is no way permissions could have got screwed up in Kyle's trash without some process - Kyle's or Adobe's - somewhere and at some point in time having got Kyle's administrator password.

It could have been on the 'install': Adobe could have marked one or more executables as 'SUID root'. When run they'd run as root, and when root runs and saves files or creates directories, guess who owns them?

Finally, a command line that might have saved Kyle.

sudo chown -R 501 ~/.Trash; find ~/.Trash -type f -ok rm -f {}\;; rm -fr ~/.Trash/.*; rm -fr ~/.Trash/*;

It first assumes ownership of everything in there; then deletes all the ordinary files; then goes after any dotted directories; then goes after the rest.

But even the above command line doesn't have to do it: anything running as root can also set the special system flags and they can require booting into single user mode to be reset.

Any time root's involved you can end up in trouble.

There are lessons to be learned here. Of course there are.

  • Never panic.
  • Don't carry coals to Newcastle.
  • You don't need 148 KB on disk to replace a 24 byte command line anyway.
  • Understanding how Unix directories work would have made all the difference in the world.
  • Rebooting, Safe Mode, booting from an install CD, et al, and above all repairing permissions are Bad Choices™.

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.