Advertisements

Monthly Archives: April 2016

how to log out another user without logging in – updated

Screen Shot 2016-04-30 at 20.35.31

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):

log out window

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 loginwindow.

activity monitor

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
end if
end repeat

Advertisements

how to stop ransomware infecting a backup disk

caged_egg

 

If you use a scheduled backup task such as Time Machine or Carbon Copy Cloner, any ransomware infection of your internal drive could soon propagate to your scheduled backup.

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. 🙂

Screen Shot 2016-04-29 at 11.00.23

 

 

Picture Credits: ‘Caged Egg’ by Marije Berting

 

 

%d bloggers like this: