Check java browser plugin enabled/disabled state and Flash version

With all the press about the Flashback trojan, OS X users would be well advised to check that their java browser plugin is disabled. You can do so by visiting this java test page. In a similar vein, check you are up-to-date with flash at the adobe site.

Determining which applications use iCloud and push notifications on OS X

Entitlements are set by the developer in Xcode at build time, and are used to control access to iCloud, Push Notifications, and the Application Sandbox. You can see the entitlements of an app using the codesign utility. Here's safari showing it is iCloud enabled for bookmark syncing via the iCloud key-value store:

$codesign -d --entitlements - /Applications/Safari.app
Executable=/Applications/Safari.app/Contents/MacOS/Safari
??qq?<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>com.apple.private.accounts.allaccounts</key>
        <true/>
        <key>com.apple.developer.ubiquity-kvstore-identifier</key>
        <string>com.apple.Safari.SyncedTabs</string>
        <key>com.apple.private.tcc.allow</key>
        <array>
                <string>kTCCServiceAddressBook</string>
        </array>
</dict>
</plist>

Here's a nasty bit of shell foo to get a list of apps:

find /Applications/ -name "*.app" -type d -exec codesign -d --entitlements - {} \; 2>&1 | grep com.apple.developer.ubiquity --before-context=3 --after-context=4

Similarly apps that use Apple push notifications will have a 'com.apple.private.aps-connection-initiate' entitlement:

$ codesign -d --entitlements - /Applications/iTunes.app/
Executable=/Applications/iTunes.app/Contents/MacOS/iTunes
??qq<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>com.apple.private.aps-connection-initiate</key>
 <true/>
</dict>
</plist>

And you should also be able to see the push notification TCP connection being held open. This is created once and used by all the apps consuming push notifications:

$ sudo lsof -iTCP 
COMMAND    PID    USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
[snip]
applepush 279 root    7u  IPv4 0xa27f1934fb5654ef      0t0  TCP hostname.myorg.com:52236->nk11p01st-courier023-bz.push.apple.com:5223 (ESTABLISHED)

Enumerating network listeners and IPC sockets on OS X

TCP listeners are easy, this gives you numeric port numbers for sockets in state LISTEN:

$ sudo lsof -P -iTCP -sTCP:listen
COMMAND PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
launchd   1 root   21u  IPv6 0xffffff8014bfb9c0      0t0  TCP localhost:631 (LISTEN)
launchd   1 root   22u  IPv4 0xffffff8014c00500      0t0  TCP localhost:631 (LISTEN)
launchd   1 root  179u  IPv6 0xffffff8014bfb600      0t0  TCP *:22 (LISTEN)
launchd   1 root  183u  IPv4 0xffffff8014bfda40      0t0  TCP *:22 (LISTEN)

And UDP is similar, but you don't get the state information (the FAQ says you should be able to specify "-sUDP:^idle" and similar, but lsof 4.84 on Lion wouldn't accept it):

$ sudo lsof -P -iUDP
COMMAND    PID           USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
launchd      1           root   13u  IPv4 0xffffff8014647dd8      0t0  UDP *:137
launchd      1           root   14u  IPv4 0xffffff8014647c60      0t0  UDP *:138
UserEvent   14           root    6u  IPv4 0xffffff801561b8d0      0t0  UDP *:*

If you are going to script these I find these commands give the fastest and most useful answers:

lsof +c15 -P -n -iUDP -u^_mdnsresponder
lsof +c15 -P -n -iTCP -sTCP:listen

You might also be interested in launchd daemons listening on UNIX domain sockets for IPC, and xinetd-style (look for the inetdCompatibility key) daemons. Here is a quick and dirty bit of python to look for enabled daemons using sockets (you will want to check /Library/LaunchDaemons too):

#! /usr/bin/python
import os
from Foundation import NSDictionary

def GetPlistKey(plist, key):
  mach_info = NSDictionary.dictionaryWithContentsOfFile_(plist)
  if mach_info:
    if key in mach_info:
      return mach_info[key]
  else:
    return None

for plist in os.listdir('/System/Library/LaunchDaemons'):
  plist_path = os.path.join('/System/Library/LaunchDaemons', plist)
  sockets = GetPlistKey(plist_path, 'Sockets')
  disabled = GetPlistKey(plist_path, 'Disabled')
  if not disabled and sockets:
    print plist_path

Secure delete 'shred' equivalent for OS X

OS X ships with srm instead of shred. Functionality is fairly similar, the default operation is a 35-pass Gutmann algorithm, which can be rather slow. Here are the timing results using the defaults and then the fast option (single random pass, then zeros) on 50M files:

$ time srm random_test

real 0m22.623s
user 0m2.847s
sys 0m0.417s

$ time srm -sz random_test2

real 0m1.527s
user 0m0.349s
sys 0m0.046s

Unless you are feeling super paranoid this is the best option:

srm -sz file_to_delete 

MCE Remote FINTEK eHome Infrared Transceiver 1934:5168 and lirc

I bought the "OEM HP MCE KIT REMOTE CONTROL/USB IR RECEIVER/EMITTER" from amazon after seeing comments it was plug and play with MythTV. Turns out not so much, at least for the version I'm running on Ubuntu lucid.

lsusb looked like this, I was expecting some sort of device manufacturer strings, so that seemed ominous:

$ lsusb
[snip]
Bus 004 Device 002: ID 1934:5168  

and in syslog:

kernel: [ 1005.516531] usb 4-2: new full speed USB device using uhci_hcd and address 2
kernel: [ 1005.691272] usb 4-2: configuration #1 chosen from 1 choice

I followed the ubuntu community doco to add my remote to the lirc src and install the new module. The patch was:

--- /usr/src/lirc-0.8.6/drivers/lirc_mceusb/lirc_mceusb.c.old 2012-04-21 14:48:41.000000000 -0700
+++ /usr/src/lirc-0.8.6/drivers/lirc_mceusb/lirc_mceusb.c 2012-04-21 15:07:57.000000000 -0700
@@ -210,6 +210,8 @@
  { USB_DEVICE(VENDOR_FINTEK, 0x0602) },
  /* Fintek eHome Infrared Transceiver (in the AOpen MP45) */
  { USB_DEVICE(VENDOR_FINTEK, 0x0702) },
+ /* HP MCE */
+ { USB_DEVICE(VENDOR_FINTEK, 0x5168) },
  /* Pinnacle Remote Kit */
  { USB_DEVICE(VENDOR_PINNACLE, 0x0225) },
  /* Elitegroup Computer Systems IR */

Remove the old stuff, build and install the new, restart lirc:

sudo dkms remove -m lirc -v 0.8.6 --all
sudo dkms add -m lirc -v 0.8.6
sudo dkms -m lirc -v 0.8.6 build
sudo dkms -m lirc -v 0.8.6 install
sudo /etc/init.d/lirc restart

And you should see a syslog line like this when you plug it in:

kernel: [ 3713.864034] lirc_mceusb[5]: FINTEK eHome Infrared Transceiver on usb4:5

The /etc/lirc/hardware.conf should look like:

#Chosen Remote Control
REMOTE="DViCO_Dual_Digital"
REMOTE_MODULES="lirc_dev lirc_mceusb"
REMOTE_DRIVER=""
REMOTE_DEVICE="/dev/lirc0"
REMOTE_LIRCD_CONF="dvico/lircd.conf.fusionHDTV"
REMOTE_LIRCD_ARGS=""

Test with 'irw' and pressing some buttons. For some reason I had to change the remote name everywhere in my ~/.lirc/mythtv and ~/.lirc/mplayer to what irw thought it was (DViCO_Utraview).

And, it works! I'm certainly not the only person struggling with this IR receiver, but apparently it is supported by the new kernel driver.

Python csv reader and namedtuple: together at last

Here is a really tasty code snippet that is a good example of the power of combining named tuples with the python csv reader.

with open(myfilename, 'rb') as f:
  LogLine = namedtuple('LogLine','fqdn,ip,user')
  for line in map(LogLine._make, csv.reader(f)):
    print 'user %s visited %s from %s' % (line.user,
                                          line.fqdn,
                                          line.ip)

What's going on here?

1. csv.reader(f) reads from the file descriptor f line-by-line and returns an array like ['user','blah.com','192.168.1.1']
2. We use map to call LogLine._make on each member of the csv iterator (i.e. each line), which creates a LogLine tuple from the array.
   

The advantages are:

• No need to split() and strip(), the csv reader figures it out for you.
• No referring to line[0], line[1] etc. forgetting which one is which, and having to change a bunch of code if you add a field or the order changes. The tuple gives you names that are human readable and the file structure is contained in one place, the tuple constructor, so changes to fields are simple.
  
• Also, if you aren't familiar with the 'with' statement, it is very nice for working with files since it replaces the 'try: read, finally: close' boilerplate code.