Simple AFP Forensics using Access Logs

Mac OS X Server’s AFP server access logs aren’t the greatest (no full paths is a glaring omission), but if you have them enabled, they can be useful for finding who deleted a file or folder for example.

If the item’s name starts with “Important File”, this command gives us the ip address of the client that deleted the item :
file_server:~ root# grep -i "Delete Important File*" /Library/Logs/AppleFileService/AppleFileServiceAccess.log
IP 10.1.21.6 - - [08/Jul/2008:14:26:14 -0500] “Delete Important File 2009.xls” 0 0 0


Then we pass the ip address into this command to give us the login of the user:
file_server:~ root# grep 10.1.21.6 /Library/Logs/AppleFileService/AppleFileServiceAccess.log | grep Login
IP 10.1.21.6 - - [08/Jul/2008:09:05:43 -0500] “Login mpickens” 0 0 0


Finally we can use dscl to lookup the full name the user:
file_server:~ root# dscl localhost read /Search/Users/mpickens RealName
RealName: Pickens, Mary Ellen


Older logs are available too in zipped form. Use gunzip -c to read the contents.
file_server:~ root# gunzip -c '/Library/Logs/AppleFileService/AppleFileServiceAccess.log 12.11.07.gz' | grep Login | grep mpickens
IP 10.1.21.143 - - [14/Dec/2007:19:12:38 -0500] “Login mpickens” 0 0 0
IP 10.1.21.143 - - [14/Dec/2007:19:24:32 -0500] “Login mpickens” 0 0 0
IP 10.1.21.143 - - [17/Dec/2007:09:21:38 -0500] “Login mpickens” 0 0 0
IP 10.1.21.143 - - [17/Dec/2007:10:37:49 -0500] “Login mpickens” 0 0 0
…


get parent process from ps

While booted from NetRestore I couldn’t figure out what was launching Terminal.app. Finally found the script that was launching it using an option the ps to show the parent process.

Simple, but useful.

ps auxww -o ppid

It was rc.install.

Shell Injection with AppleScript’s do shell script

AppleScript’s do shell script capability is immensely useful, but if you are sending variable data to do shell script, always validate input and use quoted form of variableName. See the following example:

set dialogResult to (display dialog "Enter a directory name to pass to ls:" default answer ";say boo" buttons {"Cancel", "Quoted Form", "Raw"})

if button returned of dialogResult is “Quoted Form” then
try
set theCommand to “ls ~/” & quoted form of text returned of dialogResult
display dialog “Will execute:” & return & theCommand & return & “Proceed?”
do shell script theCommand
end try
else
try
set theCommand to “ls ~/” & text returned of dialogResult
display dialog “Will execute:” & return & theCommand & return & “Proceed?”
do shell script theCommand
end try
end if

Note you’ll have to fix the quotes to standard double quotes to get this to compile. I couldn’t get wordpress to cooperate.

Unix Environment Variable Scope/Security

I recently encountered a command line tool which exposed passwords in the process listing.

The command would also also accept a password as an environment variable. I was concerned with the security of storing a password in an environment variable.

This article at itworld.com does a nice job explaining environment variable scope.

Environment variables are only accessible in the shell in which they are set.

If you export the variable, it is accessible to any subshell of the shell in which it is exported. Simply logging in as another user on the system or even the same user does not allow access to the exported variable.

So, until someone corrects me, I believe that setting and exporting environment variables containing passwords in a script does protect the password from exposure. As soon as the command requiring the password has completed, the variable can be reset to an empty string to prevent any further access to the password.

Play mp3 from python on Mac

This site has a few nice little PyObjC samples.
One of them shows how to play a sound using AppKit’s NSSound. This is exactly what I was trying to do today.

And since PyObjC is built-in in 10.5, no addtional software is required.

Python is already batteries included, with PyObjC, you’ve got batteries galore.

ipython output:

In [1]: from AppKit import NSSound
In [2]: sound = NSSound.alloc()
In [3]: sound.initWithContentsOfFile_byReference_(’/System/Library/CoreServices/Setup Assistant.app/Contents/Resources/TransitionSection.bundle/Contents/Resources/intro-sound.mp3′, True)
Out[3]:
In [4]: sound.play()
Out[4]: True
In [5]: sound.stop()
Out[5]: True

No creation dates from stat

I was surprised to learn that creation dates are not included in stat output. I really thought stat would include something so basic. You get time of last access, time of last data modification, and time of last file status change, but creation date isn’t in there.

On the Mac, this info is stored in the resource fork. You can get it from the command line using GetFileInfo which is installed when you install Apple’s free Developer Tools.

/Developer/Tools/GetFileInfo -d path/to/file

In Applescript you can use info for:

creation date of (info for (choose file))

convert lines to comma separated items with tr

If you have output that is separated by new lines, but you really want it formatted into a single line with commas as separators or maybe a space as a separator, just pipe to tr.

Here is a simple example:

kserver:~ patternbuffer$ diskutil list | grep ^/dev
/dev/disk0
/dev/disk1


If we want them separated by spaces, we could do:

kserver:~ patternbuffer$ diskutil list | grep ^/dev | tr '\n' ' '
/dev/disk0 /dev/disk1


Note that there is a newline on the end of the output, so that trailing newline is also translated. So if you don’t want it there, you’ll have to chomp it off. I use sed, but use what you like.

Here is the same as above, but with commas, with sed to remove the trailing comma.

kserver:~ patternbuffer$ diskutil list | grep ^/dev | tr '\n' ',' | sed 's/.$//'
/dev/disk0,/dev/disk1

No ACL granularity for Extended Attributes

Recently I thought I had a great use for storing extended attributes. I needed to store the time a file had been updated by my file management system without effecting the actual file modifications times. Storing this information directly in the file metadata would ensure that it would not become out of sync with some external database tracking this information.

I wanted this data to be modifiable only by a specific user or group. Unfortunately, setting an ACL on extended attributes applies to all extended attributes. I didn’t want to disallow users from setting their own extended attributes on these files and folders, so I abandoned the idea.

I wonder if we’ll ever be able to set permissions on specific attributes.

rsync 3.0 looking very promising

A little while back, I mentioned the sad state of rsync in Mac OS X. Well I’ve had a chance to test rsync 3.0 prerelease 7 and I am very pleased with the results.

To test for yourself, download the source, extract the source, cd into the extracted directory, run ./configure, run make, and then make install. You’ll find the new rsync installed at /usr/local/bin/rsync. View the man page using man -M /usr/local/share/man rsync.

Use -X for extended attributes ( and resource forks )
Use -A for ACLs
Don’t use -E, which was Apple’s flag for these as it is used for executability

Here are my test results:

Resource Fork Handling: For testing resource forks, I used to keep a copy of SimpleText around as it is all resource fork and no data fork, but a text clipping, which is also all resource fork is a great test. rsync 3 syncs the resource fork exactly the way you’d like. It retains the fork during the initial copy, and only re-copies the file if the fork has changed. This is quite awesome since Apple’s bundled rsync always copies the fork causing major speed hits even when no files have changed. I haven’t looked at the source code to see how rsync determines if the resource fork changed, but it seems efficient so far, though they may be doing checksums because using the -X flag adds time to the compare phase.

I dragged a text clipping into my source folder. I verified its resource fork using cat somefile/rsrc. I ran rsync and verified the destination’s resource fork. I re-ran rsync and no files were copied. I appended some data to the fork and rsynced again. rsync detected the file as changed and re-copied it with the changed resource fork. You can test it yourself. Using the –stats or -v option, try running Apple’s rsync, then rsync 3 and you’ll see the number of files transferred.

Metadata tests: I recently found backup bouncer, which runs a multitude of tests on metadata preservation.

------------------ rsync-3.0pre7 ------------------
This copier exited with error code 23
This copier produced log output in:
/Volumes/Dst/11-rsync-3.0pre7/log
Verifying: basic-permissions … ok
Verifying: timestamps …
Sub-test: modification time … ok
ok
Verifying: symlinks … ok
Verifying: symlink-ownership … ok
Verifying: hardlinks … ok
Verifying: resource-forks … ok
Verifying: finder-flags … ok
Verifying: finder-locks … FAIL
Verifying: creation-date … FAIL
Verifying: bsd-flags … ok
Verifying: extended-attrs …
Sub-test: on files … ok
Sub-test: on directories … ok
Sub-test: on symlinks … ok
ok
Verifying: access-control-lists …
Sub-test: on files … ok
Sub-test: on dirs … ok
ok
Verifying: fifo … FAIL
Verifying: devices … FAIL
Verifying: combo-tests …
Sub-test: xattrs + rsrc forks … ok
Sub-test: lots of metadata … ok
ok

Overall it fares pretty well.

The lack of support for finder-locks (aka flags like uchg) is unfortunate. Files on the destination are simply unlocked. This solves the problem of rsync not being able to delete locked (uchg) files, but it is kind of worse because that metadata is just plain lost and a lot of old time Mac users are accustomed to using that feature since it is right there in the GUI Finder Get Info panel.

I suppose a workaround would be to find all the files that have the flag and create a transcript of them before running rsync for later re-locking.

I need to do some performance testing compared to rsyncx, but so far, rsync 3 looks good to me.

A history of rsync on Mac OS X

I think Apple included the rsync binary with Mac OS X since at least version 10.2 Jaguar, but it couldn’t be used for backups of most Mac data due to its lack of support for resource forks, which were and are prevalent on the Mac.

Rsync first got attention on Mac OS X when Kevin Boyd of University of Michigan added support for resource forks to rsync with a port he called RsyncX. RsyncX also included a simple GUI for setting up backups. The GUI generated shell scripts and scheduled them in cron. The GUI was buggy and generated scripts with minor, but serious flaws. The scripts also lacked some necessary features that a backup solution would provide. But with the lack of a good backup solution (just say no to Retrospect), some admins including myself took the time to customize and extend the scripts that RsyncX created, or just created new ones from scratch. I added features to my scripts like checking for free disk space, rotating incremental backups with hard links, checking for a mounted volume before running, failure notifications, etc.

RsyncX had other flaws though. It was based on older rsync code which contained bugs and at least one serious security vulnerability. One of the bugs results in rsync getting stuck in an endless loop if files are changing while rsync is running. If you have logging enabled, rsyncx will quickly fill your drive while it is stuck in this loop — really bad news. My workaround for this was to spawn rsync off and watch its log every few seconds for telltale signs that it was stuck in a loop. I would then kill rsync and restart it. Ugly, but it actually works. Oh yeah, it also doesn’t know how to handle locked files (uchg), so I have to unlock all files on the destination before the sync. Ugh. Oh and it throws lchown errors on symlinks. Just grep -v them out.

When Apple began talking about the features of Mac OS X 10.4 Tiger, one of the big features for command line unix geeks was support for resource forks in all command line tools, including rsync. By this time those of us using RsyncX were getting pretty tired of all of the workarounds and bugs, so an Apple supported rsync that handled resource forks was awesome news.

When rsync was released with 10.4.0, it has serious bugs. It was basically unusable. It would crash unexpectedly with large data sets. It would incorrectly set modification dates, which would then cause all future syncs to re-copy all files. I stayed with rsyncx to handle production syncs with the additional slap in the face of deprecated warnings filling the system log. With each new release, I would test Apple’s included rsync. I filed bugs. I used a developer support incident. Finally around 10.4.9 and later, rsync did actually seem to work, at least well enough. In real world tests though, Apple’s rsync speed was and is dismal on large data sets. The problem lies in the fact that resource forks do not have a modification date to compare when syncing. Without this key piece of data, there is no easy way of knowing whether the resource fork of a file has changed or not. Apple’s solution to this problem was to ALWAYS COPY the resource fork. That’s right, if your data has resource forks, you copy the resource data every time rsync runs. Yes, resource forks are typically small, but they add up, and for terabytes of small files, the I/O causes an rsync of unchanged data that should take about 30 minutes to instead take 4 hours.

So again I stick with RsyncX.

Leopard’s rsync appears to be virtually unchanged from Tiger’s at least to me. It still copies the resource fork every time.

Mike Bombich apparently likes rsync too. He is using it for the sync engine in Carbon Copy Cloner 3. He includes an updated patched version in the bundle here: Carbon\ Copy\ Cloner/Carbon\ Copy\ Cloner.app/Contents/Resources/ccc_helper.app/Contents/Resources/rsync

One nice thing about this binary is that it has a patch to optionally checksum resource forks (–ea-checksum) to prevent them from being copied unnecessarily. Cool, but checksumming adds time, so I’ll need do some real world tests.

Rsync version 3.0 is in prerelease and includes built-in ACL and extended attribute support. Hopefully this includes some way of handling unchanged resource forks.

Until Apple adds some sort of date stamp to resource forks, checksums may be the only safe way to handle them. I suspect that addressing the issue properly will have to wait for a new filesystem.