0

I've created uninstaller for my driver, that remove its matching plist file from /Library/LaunchDaemons so that it won't be loaded again by launchd on the next boot cycle. However, it doesn't seems to take any effect on my driver that is still being loaded normally after booting the machine.

After doing some research in this matter, I've found out that the kextcache is the reason for this behaviour, and in order clean/invalidate it, I need to touch the folder where the installation target volume. however, it haven't had any effect.

My question is how to properly invalidate the kext cache so that launchd won't load the kext after it's corresponding plist file was removed.

Thanks to the answer below, I invalidated kext cache. However, I'd like to have the equivalent for access existing folder in objective-c which my uninstaller helper is based on.

To be precise, here's the code I'd like to convert to objective-C:

sudo touch /System/Library/Extensions; sudo touch /Library/Extensions

Zohar81
  • 4,554
  • 5
  • 29
  • 82

1 Answers1

2

The proper way to invalidate the kext caches is

sudo touch /System/Library/Extensions

or in OS versions that support loading extensions from /Library:

sudo touch /Library/Extensions

As soon as you do this, the kext caches are automatically regenerated.

dgatwood
  • 10,129
  • 1
  • 28
  • 49
  • It seems to work when i type it manually, but when i ran it from applescript via objective-c uninstall helper i didn't do anything. perhaps you can tell me what's wrong with my code `NSString * script = [NSString stringWithFormat:@"do shell script \"touch /Library/Extensions/; touch /System/Library/Extensions/\" with administrator privileges"]; NSAppleScript *appleScript = [[NSAppleScript new] initWithSource:script];`. notice that i ran it under privileged mode – Zohar81 Sep 06 '16 at 21:42
  • I would also happy to hear if you have better way to do this command from uninstallerHelper that is written in objective-C, but i might consider to change it to other language if it will be worth the effort. – Zohar81 Sep 06 '16 at 21:51
  • You need to use an absolute path to /usr/bin/touch, because the PATH environment variable is deliberately empty in that environment to prevent helpers from being used to run arbitrary code as root. – dgatwood Sep 06 '16 at 22:53
  • If that doesn't help, try running it directly with posix_spawn, e.g. `pid_t pid = -1; char *args[] = { "touch", "/Library/Extensions", NULL}; posix_spawn(&pid, "/usr/bin/touch", NULL, NULL, args, NULL);` and see what it returns and what `errno` equals. – dgatwood Sep 06 '16 at 22:56
  • If you use that approach, don't forget to `waitpid()` for the process afterwards. – dgatwood Sep 06 '16 at 22:57
  • thanks for the help, It did the job except that I must run this code snippet with elevated permissions. perhaps you can advise my what is the best way to do so ? should I ran it from shell script or from remote helper that will be called by the uninstaller using `SMJobBless`. thanks again ! – Zohar81 Sep 07 '16 at 06:40
  • Ah. I assumed you were already running it with elevated permissions. How are you deleting a file from /L/E or /S/L/E without being root? In any case, yes, you should run the touch command from some code that will be running as a privileged user (whether that got started with SMJobBless or something else), whether that code is AppleScript, a shell script, or compiled code. Sorry, the whole time I was thinking that you were doing this in a postinstall script in an installer package. :-) – dgatwood Sep 07 '16 at 06:46
  • In order to delete the daemon plist file, i call a dedicated standalone executable (helper) from my installer using the already deprecated method of `AuthorizationExecuteWithPrivileges`. I'd like to replace it with some well supported and documented method. I'm thinking of using SMJobBless. however, i'm not sure how it perform the permission elevation. – Zohar81 Sep 07 '16 at 06:54
  • I haven't personally worked with SMJobBless, so I couldn't tell you, but within your standalone helper, you should be able to delete the file. – dgatwood Sep 07 '16 at 06:55
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/122805/discussion-between-zohar81-and-dgatwood). – Zohar81 Sep 07 '16 at 08:41
  • Have you looked at the utimes() system call? from the man page: int utimes(const char *path, const struct timeval times[2]); The access and modification times of the file named by path or referenced by fildes are changed as specified by the argument times. – silicontrip Jul 16 '20 at 02:41
  • Unless there's a bug in Apple's implementation, you must be the owner of the file, have write permission, or be root to modify the modification time with that system call. – dgatwood Jul 16 '20 at 21:33