Posted: 10th May, 2013
If you have multiple accounts on your mac, you may sometimes wish to log out one or more of those accounts without actually having to sign in to them first via the fast user switching menu. There’s a couple of ways to do this. First, if the issue is just that you want to shutdown the computer, you can log out all users by entering an Admin user name and password when this dialogue automatically appears after hitting ‘Shutdown’ (it won’t appear if no other users are logged on):
However, there are times when you may just want a quick way to log out users without shutting down and without wasting time logging in to their accounts first. Be aware that in killing a user’s process without logging in to the account first, any data in that user’s account that is not already saved (or autosaved) will be lost. If you’re sure that’s not a problem, then follow this short procedure manually or use the AppleScript version that follows:
1. Open up Activity Monitor (/Applications/Utilities/Activity Monitor.app)
2. Use the drop down menu in the Task bar to change the menu to ‘Other User Processes’ (note: you can use ‘All Processes’ in the menu if you wish, but that is less safe as it makes it possible to accidentally click on your own user process in step 4 below!).
3. In the filter bar, type
4. From the list of users that show up, for each one that you wish to log out:
- click on its row in the Activity Monitor pane to highlight the process
- press the ‘Quit Process’ icon in the Task bar above
- from the resulting dialogue window, click ‘Force Quit’
- supply an Admin password if requested.
Repeat for any further accounts that you wish to quit. (Tip: If you want to kill the ‘Guest User Account’, you’ll need to switch back to ‘All Processes’ and kill the loginwindow assigned to the ‘root’ user).
And that’s it. Your unwanted users are now logged out!
Update 30th April, 2016: If you get tired of doing this manually, you can log out all other real users at once with this AppleScript:
set thisUser to do shell script "whoami"
set usrList to paragraphs of (do shell script "ps caux -o args | grep loginwindow")
repeat with i from 1 to number of items in usrList
set this_item to item i of usrList
set thatUser to word 1 of this_item
if thisUser is not equal to thatUser then
set theProcessNum to word 2 of this_item
do shell script "kill -9 " & theProcessNum with administrator privileges
To help ameliorate that, I’ve produced a script that will abort a scheduled backup task using Carbon Copy Cloner if a user-defined percentage of changes have occurred in a designated ‘Canary’ folder.
Here’s how it works. In order to be successful, ransomware must change a large percentage, if not all, of your personal files in your Home folder by encrypting them. That means we can determine if a folder has been encrypted by looking for an unusual amount of changes or additions since the last backup.
A Canary folder is a folder that we use to warn us of precisely that. It should be a folder that contains some random dummy files (.doc, .png, .xls files etc), and/or a folder which you don’t make large changes to from one backup to the next. The script itself will change the folder slightly each time it runs, to ensure that the Canary folder does not look like it’s ‘stale’ (which might cause an attacking script to ignore it).
The key to the Canary is that the percentage of files changed or added on each scheduled backup is less than the threshold you set in the script. The default is set to no more than 10%. If the number of files changed or added is higher than that, then the backup aborts. You can of course change the default to a bit higher if you use a ‘real’ folder that you don’t change often, but remember we’re only talking changes between one scheduled backup and another, so it will also depend on how frequently your backups are scheduled.
For example, I have a 2-hour scheduled backup and I use my ‘Documents’ folder as the Canary. Since I only use that folder for long-term archives, it is actually rarely changed, and certainly never as much as 10% within 2 hours, and that makes it a perfect choice as a Canary. You can pick any real, rarely used folder or you can set up a complete dummy folder if you prefer.
If you do pick a real folder, keep in mind its size. The larger the folder, the longer it’s going to take the script to determine the differences between it and the last backup of it. A couple of thousand files is OK, but once you get into the tens of thousands you might find the script takes several minutes to complete. With only a few hundred files in my Documents folder, it takes literally a second or two.
Here’s a sample output from the log file the script produces in the ‘Canary’:
Destination /Volumes/Backup Disk/Users/phil/Documents has 360 files in the folder. There are 3 changes between it and the source /Users/phil/Documents. The threshold for aborting the task is 10 percent, or 30 changes. Result: task will run.
For our strategy to be successful, we need to ensure the attacking script doesn’t ignore the Canary and does try to encrypt the Canary before the next backup is scheduled. For that reason, if you opt for a complete dummy folder, you might like to give it a name so that it’s somewhere near the beginning (alphabetically) of your Home folder. Since the Canary folder will be slightly modified each time the script runs, it should get hit early if the attack is looking either for recently modified files or just starts trawling your home folder in ascending name order (and I know what you’re thinking: what about descending order? Sure, you could add another Canary at the end, and modify the script to check both ;)).
Note that this script is for use only with a regular, scheduled backup task, and only for use with Carbon Copy Cloner (version 4). We’ll be posting about Time Machine strategies later.
Another note of caution is that while this script should stop your scheduled CCC task from infecting a backup drive, it won’t stop an attacking script from attempting to encrypt any mounted drives it finds by itself. That really depends on the sophistication of the attack. To that end, we’ll soon be posting a general strategy for detecting a ransomware attack on your internal drive using multiple Canaries and a bit of Folder Action script magic. Stay tuned for that.
In the meantime, here’s the script. Due to the vagaries of WordPress.com formatting, I’ve hosted it over on my pastebin. Please read the extensive comments, which also explain how to set it up and how to use it. Any questions, drop a comment below.
Picture Credits: ‘Caged Egg’ by Marije Berting
This update sees the introduction of a major new feature, the TaskPad. If you’ve ever been frustrated by the limitations of Apple’s Notes and Reminders apps and wondered why they didn’t, well, just combine the two, then FT2’s TaskPad may be for you.
Inspired by one of my favourite free apps from the Snow Leopard era, Lighthead software’s Remember.app (still available but sadly never updated to 10.7 and beyond), the TaskPad keeps things light and simple, while having a lot of power to keep you organised and on task.
You can set due dates, add rich-text notes, as well as order and re-order via drag and drop. If you want to use the same database across more than one mac, that’s possible, too (requires an independent syncing service such as Dropbox or similar). You can also maintain more than one list database and switch between them as you need.
Since FastTasks is all about being fast, you don’t need to wade through the main menu to call up the TaskPad (though of course you can do that if you want!). Just hold down the Command key and click the F2 icon and the TaskPad will immediately appear.
Another change in this update is that the Eject Disks function will now let you eject individual disks as well as all disks. We’ve also updated the Analyser with new definitions.
The FT2 2.8 update is available to users on 10.10.5 or above. Unfortunately, FT2 no longer supports OS X Mavericks, but 10.9 users can still download the previous version (2.7) of FT2 for the time being.
We’re now up to v2.22 of DetectX.
The major change is that we’ve moved to a generous 60-day trial period for non-license holders. Prices for home use and commercial use remain at $15 & $79.99, respectively, as promised for the remainder of v2 releases.
Heads up though, folks. DetectX 3 is nudging over the horizon (we’ve been working on it since late last year and only need to get the next FastTasks update out of the way first!) and the price of both home and commercial license keys is expected to rise for unregistered users. DetectX 3 will bring a modern UI interface and a whole new suite of tools intended to make it the most powerful tool on the market for analysing and troubleshooting you mac. If you hold a license key for any version of DetectX 2 prior to the release of version 3, you’ll get a free upgrade to DetectX 3.
The release notes for DetectX 2.22 can be found here.
It all started with 2.16, which introduced some changes to the licensing and user interface. All well and good, until we noticed a serious security issue with Microsoft Silverlight had recently surfaced, and we didn’t want to wait to address it.
That resulted in 2.17, which added a Silverlight check to the detector Search function. If you have a version of MS Silverlight that is not the currently patched version, you’ll see a warning in the log drawer when you run a search. In 2.17 we also fixed a false positive in the Keylogger detector and updated some search definitions.
Alas, we’d inadvertantly let a bug slip in with v2.16 that prevented DetectX from quitting in certain situations. Luckily that report came in pretty quick (many thanks to Al), and we were able to address the bug with a simple code tweak (if you got bit by that bug, please open and then close the Licensing window before attempting to update to v2.18).
So, here we are at version 2.18 … we’re a bit breathless, so it’s time for a sit-down and a nice cup of tea!
Yes, two in two days! We’ve added a Preference Pane since yesterday, and improved the performance of the search function. Note that the new Sparkle Vulnerability check we introduced in v2.13 is now off by default. It can be turned on from the Preference Pane (see above).
Other changes are listed in the release notes.
DetectX is still free, fully-functional, and without time-limit for home users. Available for download from here.
We’ve just released an incremental update to App Fixer. The app is free for home users and available from here.