Tuesday, February 16, 2010

How to replace FileVault with EncFS

UPDATE: I've been upgraded to Snow Leopard (10.6), and a lot of issues outlined below are solved. Recovering disk space takes a couple of seconds only, IO speed increased considerably, and backup also seems to take a lot less time. I would recommend you NOT to follow the guide below for Snow Leopard and up if these were the only items bugging you.

Background

MacOSX comes with a built-in encrypted filesystem: FileVault. Its purpose is to protect private data stored on your computer. It does its job quite nicely, but far from perfect. Me, coming from the linux world, was quite put off by its limitations, so I started looking for an alternative that would make me happy.

FileVault is an encrypted filesystem. This means that is doesn't encrypt files, it encrypts partitions. How it works is when you hit the button 'Turn on FileVault' in the security preferences, it creates a dynamically growing file in your home that contains the encrypted contents of your original home. When you log in, this is mounted, using your login password. The whole operation is seamless. In the background, it is relying on the diskimages framework. If interested, check man hdiutil for details and more options.

In earlier releases of FileVault, the whole encrypted home was a single huge file on the filesystem. Whenever growth was necessary, it increased the encrypted file size. However, this caused problems for Time Machine, Apple's built-in backup tool. Since the file is encrypted, it was not possible to make incremental backups, so Apple decided to implement a feature called 'sparsebundle', that splits this huge file in 8MB chunks, so that Time Machine can make incremental backups of the encrypted home.

You can see how problems stack up. It's not only FileVault, but how it works with other applications, most importantly Time Machine.

This HOWTO was written on a Mac OS X 10.5. Other versions may or may not work - you'll have to figure it out yourself. The idea and the commands are the exact same once you get encfs installed properly.



FileVault: pros and cons


- Long waiting times at logout
- No shrinking while logged in
- Doesn't work well with Time Vault
- Proprietary

+ Well worked out and tested
+ Encrypts you entire home for better privacy



Why

  • Get your space back

    For example, if you have a 300GB disk, and you copy 50GB into your home temporarily, MacOS will expand the sparsebundle to accommodate the extra 50GBs. However, after you've removed it, it will not shrink it, and it will be recovered only after you log out. Until then, 50GBs will be gone from your 300GB disk, and only be available in your encrypted home dir.

    EncFS is a file-based encryption, and it relies on the existing file system for storage, so this issue simply does not exist; the encrypted and decrypted directory share the same partition, and thus, disk space.


  • Get rid of the long waiting times at logout

    FileVault is very slow. In the before example, it takes FileVault about 20-30 minutes to recover the disk space it has allocated to the encrypted filesystem earlier. This of course is done when you are logging out, waiting for the laptop to reboot, shut down, etc..., so basically, from your own time.

    EncFS stores its encrypted files in the same partition, and thus, it has no such problems whatsoever.


  • Back your data up while logged in

    With FileVault, there are no backups made while you're logged in. This is again caused by the bad design of filesystem-in-a-filesystem. Data is backed up when you logout - but then it takes quite a while.

    Take for example the case when you copy 100GB in your homedir, and then erase 50GB. On logout, FileVault will take 20-30 minutes to recover disk space, and then Time Machine will take another 20-30 minutes to back the extra data up.

    Using EncFS, backups are done on-the-fly, while you are logged in. This means you can stay logged in as long as you like, there is no need to log out just to make a backup of your homedir, like you had to do with FileVault.


  • Be flexible

    EncFS is fully open source. You know what's going on in the background. You can fine-tune the encryption to your needs. You can even have more than just your home encrypted. You can use different encryptions on different parts of your system (a 128bit for your pictures and a 256 bit for your emails, for example). You don't have to encrypt your home, only the parts that you need. It's all up to you.

    You can also have better interoperability with other tools. Since it is fully file-based, you have the ability to process the encrypted directory to your liking, in your own way.



    Why not

    FileVault is a lot more tested than EncFS. There are known problems with EncFS, as it only support basic POSIX operations (no locking, extended attributes, etc...). This works well for simple file storage or multiplatform applications, like MacPorts, Firefox, Thunderbird, etc..., but encrypting your whole homedir is known not to work. As a consequence, you are losing some privacy, leaving parts of your home unencrypted. If you are sensitive about this, or you are unsure whether you won't leave important data uncrypted, don't go ahead.

    Because EncFS encrypts on file level, the number and size of files will be exposed in the encrypted dir. This is not a big deal, just go check out the contents of the encrypted directory for yourself. You'll probably keep wondering what the heck is in there, even though you know what you are storing there.

    You also need to spend some time to evaluate what and how you want to protect. Setting up EncFS will take some time, it's not just clicking a button and going for lunch while it finishes.

    If you are not a geek, don't do this - it's not meant for you. I would say the baseline is setting up and using macports - if you can do that, this will not be a problem, either.



    How - the easy way

    You can use macfusion to set up encfs via GUI. I won't go into details, as I observe this method to be inferior to command line.

    It is a good tool for non-geeks to encrypt their data, though, if you don't mind some click-click now and then.



    How - the geek way

    Once you have macports installed, set up encfs:


    $ sudo port install encfs


    The next step is to organize your mounts. How I did it was I've created /e and /e.crypt and chown'd it for my user:


    $ sudo mkdir /e /e.crypt
    $ sudo chown llama /e /e.crypt


    Of course, you can create multiple directories for multiple users if needed.

    The next step is to set up the encrypted directory. This can be done by:


    $ encfs /e.crypt /e


    On the first run, encfs will guide you through the setup options. If unsure, just pick the default options (by simply hitting enter) for every question, they are well defined.

    Now you have your encrypted directory in /e.crypt and your decrypted directory in /e. The next step is to decide what you want to encrypt. It's fully up to you. I went with the configuration directory of ssh, Thunderbird and Firefox.

    Don't forget that encfs doesn't support fancy filesystem operations, so don't just throw your whole homedir in there - it won't work.

    The next step is to copy your stuff there and create a softlink on the original location:


    $ mv .ssh /e
    $ ln -s /e/.ssh
    $ mv Library/Thunderbird /e
    $ ln -s /e/Thunderbird Library/
    $ ...


    So, now you have the final setup. The next step is to make mounting/unmounting automatic on logon/logoff. For this, we are going to use the so-called login hook. This is a special Apple feature; in short, it lets you define an executable that is executed after login, but before changing UID to the user - so, practically at the point when all login-related tasks have been done by root, and we are about to change UID to the user. We will use this to mount our encrypted directory.

    Now, we want an automatic mount of the encrypted volume on login. This is handy if you have Firefox and Thunderbird started up on login.

    How I've solved this was putting the password in the user's keyring. That's a safe storage for passwords. So open the Keychain Access application (easiest is from the little lock in the menubar), pick the Login keychain, category Passwords, and add a new key in there. Set the keychain item name and account name to 'EncFS', and the password to the password that you given to encfs during the first-time initialization.

    Now let's create the script that is to be executed as login hook. Create file /usr/local/sbin/loginhook, and copy the following into it:


    #!/bin/bash
    # $1 = logged in username
    # try to mount /e using encfs entry in keychain
    su - $1 -c "security find-generic-password -ga EncFS" 2>&1 >/dev/null | cut -d'"' -f2 | sudo -u $1 /opt/local/bin/encfs -S /e.crypt /e


    What it does is grabs the password you've added to the login keychain using the command-line tool 'security', and pipes it into encfs executable, using the '-S' flag to tell it to fetch the password from standard input.

    Next we create the logout hook. It is the exact same as loginhook, but executed at logout. So create the file /usr/local/sbin/logouthook, and copy this into it:


    #!/bin/bash
    # $1 = logged out username
    # try to unmount /e
    umount /e


    Yes, it simply unmounts the encrypted directory on logout.

    Don't forget to set the executable bit on these scripts:


    sudo chmod +x /usr/local/sbin/log*hook


    Now, instruct the login window application where the login and logout hooks are:


    sudo defaults write com.apple.loginwindow LoginHook /usr/local/sbin/loginhook
    sudo defaults write com.apple.loginwindow LogoutHook /usr/local/sbin/logouthook


    That's it, you're done.

    If you would need to use encfs for more than one users, it is a pretty straightforward change to the above - remember, the first argument of the login and logout hooks is the username. Also, remember to store the 'EncFS' key in the login keychain, because that is specific to each user, so each of them can have different password.

    There are a lot more things that you can do with this, just use your imagination. For me, this does the job, and is perfectly extensible would the need for anything else arise.



    Conclusion

    The biggest mistake Apple did with FileVault is storing the encrypted home directory on a virtual file system. All of FileVault's drawbacks originate from this. The implementation is brilliant, free of bugs, fast and well thought over. But why they decided to have all the trouble with a filesystem in a filesystem remains a mystery.

    For me, until Apple manages to come up an encryption that is not based on a broken idea, EncFS really gets the job done. Leave a comment if this short howto helped you too.
  • 36 comments:

    yDNA said...

    s/that is based on a broken idea/that is not based on a broken idea/

    ?

    Trevor said...

    I'm not sure if putting your whole .ssh directory in there is the best idea. My first thought is that if you use certificates for authentication, you won't be able to use that method to login remotely when you aren't logged in. Maybe simply putting only your private key in there might be the a better option?

    pp said...
    This comment has been removed by the author.
    pp said...

    There is an "S" too much in the command for installing encfs, it should read:

    "$ sudo port install encfs"

    Thanks for this great article, switching to encfs in this very moment.

    (re-posted with typo removed)

    George Entenman said...

    I used FileVault to keep work stuff secure. Unfortunately a 100GB partition took about 40 minutes to close when it was time to go home!

    The answer: TrueCrypt. It's fast, reliable - it survives crashes, for example - and leaves lots of system stuff unencrypted. Perfect for me.

    Marco Schirrmeister said...

    Which OSX version do you use?

    The version in the ports does still not work on 10.6 Snow Leopard.

    Here is what you get.
    Hope it gets fixed at some time.

    --------
    $ sudo port install encfs
    Password:
    ---> Computing dependencies for encfs
    ---> Building macfuse
    Error: Target org.macports.build returned: shell command "cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_fuse_macfuse/work/macfuse-core && ./build_macfuse.sh | sed -ne '/^created: /h;p;${g;s/^created: //
    w ../dmgname
    }'; exit ${PIPESTATUS[0]}" returned error 1
    Command output: Unsupported Mac OS X release 10.2.0

    Error: The following dependencies failed to build: macfuse
    Error: Status 1 encountered during processing.
    ----------

    Henri said...

    Great article.

    Yes, TimeMachine is not currently a great backup solution if you have enabled Filevault. However, LBackup works well for the backup of your home directory while you are logged if you are using FileVault.

    Anonymous said...

    These backdoors are usually found and used against you in practice.

    RIght.

    Since our government's been arresting everyone and their child and under terroristic pretenses, I feel it's safe to say, [citation needed].

    Shiruba said...

    I am not sure why having an encrypted filesystem is considered to be a bad idea? This is what TrueCrypt does, and many of the linux encryption systems as well. This isn't bad in and of itself.

    The time machine issues come from the fact that they choose to back up the encrypted data from the "outside", as opposed to the unencrypted files on the "inside" of the filesystem when the user is logged in.

    I assume this is done to keep the backups from being the weak link in security. On the other hand, for the typical use of securing laptop data against theft when the laptop is lost or stolen, it doesn't really matter if the backup data is unencrypted.

    Using "only" 128bit AES is probably chosen as it's a good trade-off for speed and encryption for most users.

    Resuna said...

    I would not put .ssh in the encrypted file system at all, because everything that needs to be encrypted in .ssh is already encrypted.

    stolen data said...

    You, "coming from the Linux world", should know that the OS is Mac OS X, not MacOS - there are ten worlds of differences between these two. If you Wikipedia a bit, I'm sure you will learn what MacOS is.

    Unknown said...

    One big advantage of using FileVault is that every single personal setting, cache and browser history is encrypted. It appears that there are problems associated with moving ~/Library to encfs so a lot of personal information would be exposed.

    Kirsch said...

    "This means that you can be sure that there is a built-in backdoor for government bodies to use, in case you would be a terrorist suspect or trying to seize control by a coup."

    Can I be sure of that? Is there any evidence? Or are you just being paranoid or buying into conspiracy theories?

    Unknown said...

    I've been using EncFS with Macfusion for a couple of years, and it rocks! I started using it when 10.5 first came out, and everything migrated nicely to 10.6 (I needed a newer MacFUSE and Macfusion though, but the data all survived).

    I use it to store all my work documents, which need to be encrypted by our rules. My favorite thing about it is that Time Machine backs up my encrypted directory automatically (it's in my home dir). I was even able to restore all my encrypted files once after a disk crash. It's my favorite file encryption solution for the Mac.

    iSoftUsernet said...

    yOU just offer a alternative for new tools is developer get road...

    Ibi & Agoston said...

    @yDNA, @pp: Thanks, fixed!

    @Trevor: True, you have to refine it a little in that case. This HOWTO is for laptop owners, and ssh'ing in there without a local user logging in was not considered to be a requirement.

    @ge: it's the other great tool I was considering (and actually using as well), but it is still a filesystem, and as such, it retains some of the drawbacks of FileVault, as in: fixed size and no backups.

    @Marco: I use 10.5. I'm not sure why macports would have a trouble with encfs on 10.6 - maybe you can google around a bit on that one.

    @Shustak: I've checked out LBackup, it is a great tool, but still doesn't solve the problem of keeping unencrypted files on the backup disk.

    @ihatbloggerlogins, @Marcos: I hate them too :). I have no proof. However, we have seen many examples of big companies being forced into such behavior, including google, MS. I can't see why Apple would be an exception, being based in the US.

    @Shiruba: true, but the assumption was to provide something that is better than FileVault. Using truecrypt, you could the almost the same by adding the encryption of your backup disk and telling time machine to back up your decrypted home - but you would still be restrained by the fact the a truecrypt volume doesn't auto-expand or shrink.

    @Resuna: good point! Putting .ssh was an example. There is still quite a bit of info there, like known_hosts, that I wouldn't want to get exposed. The real reason I've put .ssh there is that I'm a bad-bad-bad guy and don't use a passphrase on the ssh keys, because I hate typing passwords every time I ssh-add them to the keyring. This encfs solution solves the security AND the password-typing problem at the same time.

    @stolen data: got it right, even after 1.5 years with my company-issued macbook pro, I miss my kubuntu very much. It feels like windows to me, with cygwin preinstalled.
    Good point on the version, I'll include that in the introduction, so it will be explicit. Thanks!

    @Ahlborg: Why would you encrypt *everything*? There is a lot of stuff in your home that one doesn't consider a secret.
    Good point though that if you are very sensitive about privacy, you shouldn't do this. I presumed that whoever understands this howto is able to evaluate the risk involved. I'll add this to the advantages of filevault to make this explicit. Thanks for the feedback!

    Resuna said...

    Heh. To me, anything using Gnome or KDE feels pretty Windows-like already. The way typical Linux distros have boosted so much of the API from the system call level to glibc just adds to the effect. Not that OS X is any less shlib-infected, but really... it's six of one and half a dozen of the other to an old-school UNIX geek.

    As for ssh, you do know that Leopard and later have built-in SSH-Agent support, right?

    Henri said...

    "I've checked out LBackup, it is a great tool, but still doesn't solve the problem of keeping unencrypted files on the backup disk"

    You will find that LBackup has a number of post and pre hooks for dealing with the mounting and un-mounting of disk images and storage devices on Mac OS X systems.

    Details on setting up encrypted backups is available from : LBackup : Encrypted Backups

    Keep in mind that these instructions are aimed at using hdiutil on Mac OS X for encryption.

    There is also a post action script bundled with LBackup which allows for synchronizing the complete backup set to to a remote system.

    Ibi & Agoston said...

    @Resuna: of course I'm using ssh-agent + forwarding, so the only place the key is stored on disk is encfs-encrypted.

    @shustak: Right. But with encfs, you can take backups *while* logged in, anytime, using the stock time machine software, and still, the backup will contain crypted data only. I think this method is easier in the end, but of course, as usual, there are many ways to Rome.

    Resuna said...

    I still think you would be safer keeping the ssh key encrypted at the application level, with that encryption key in your keychain, using Apple's keychain/ssh-agent integration. Otherwise your ssh key is exposed any time encfs is mounted, whether you're using ssh or not.

    Unknown said...

    Great post. I am using it right now on my newly installed MBP. It almost seems to work 100% but the login script wouldn't run here. I got an error about the first 'su - $1' part, so I removed the '-', which makes it work here. The problem is, now it pop ups an alert every time I log in, asking me for the keychain password. Really annoying. I don't know why I am the only one who has this problem?

    Unknown said...

    good stuff. however i don't want my EncFS drive mounted all the time, so I set this up in my user's crontab. Unfortunately, it prompts for the keychain password. any ideas how to not have to put the password in the cron?

    echo "keychain_password" | /usr/bin/security -v unlock-keychain; /usr/bin/security find-generic-password -ga EncFS 2>&1 >/dev/null | /usr/bin/cut -d'"' -f2 | /usr/local/bin/encfs -S /Volumes/backups/encfs /Volumes/EncFS;
    # DO STUFF
    umount /Volumes/EncFS

    Unknown said...

    I followed this procedure and got most of it to work (had trouble with the password stored in the keychain).

    There were 2 problems I had using snow leopard that I'd like to share solutions to:

    1) The update to boost 1.42 has broken encfs; you can create the inital mount but can never remount it. This is fixed by downgrading to boost 1.41 -- you need to create a local portfile and checkout from the macports SVN

    As root:

    mkdir /Users/Shared/dports

    svn co --revision 63323 http://svn.macports.org/repository/macports/trunk/dports/devel/boost/ /Users/Shared/dports/devel/boost/

    portindex /Users/Shared/dports

    port deactivate boost @1.42.0_0
    port install boost @1.41
    port uninstall encfs
    port install encfs

    This gets it working, but your unencrypted mountpoint will not be indexed by spotlight.

    To fix this, you need to add -oallow_other and -olocal to the encfs command in loginhook.

    You then need to issue one-time commands:
    sudo mdutil -i on /your_mountpoint
    sudo mduitil -E /your_mountpoint

    This adds the mountpoint to spotlight. Enjoy!

    Mouse said...

    Nice article. But the approach doesn't seem to work:


    $ sudo port deactivate boost @1.42.0_0
    ---> Deactivating boost @1.42.0_0
    ---> Cleaning boost
    $ sudo port install boost @1.41
    ---> Computing dependencies for boost
    ---> Activating boost @1.42.0_0
    ---> Cleaning boost
    $ sudo port install encfs
    ---> Computing dependencies for encfs
    ---> Fetching encfs
    ---> Verifying checksum(s) for encfs
    ---> Extracting encfs
    ---> Configuring encfs
    ---> Building encfs
    ---> Staging encfs into destroot
    ---> Installing encfs @1.5_1
    ---> Activating encfs @1.5_1
    ---> Cleaning encfs
    $ encfs `pwd`/raw `pwd`/crypto -olocal
    18:32:14 (FileUtils.cpp:375) Archive exception: stream error
    18:32:14 (FileUtils.cpp:326) Found config file /Users/admin/Src/encfs-1.5/trials/raw/.encfs6.xml, but failed to load
    Creating new encrypted volume.

    This is on Mac OS X 106.3 with all the latest patches and the latest XCode installed.

    Mouse said...

    Forgot to mention:

    $ sudo svn co --revision 63323 http://svn.macports.org/repository/macports/trunk/devel/boost/ Users/Shared/dports/devel/boost/
    Password:
    svn: '/repository/macports/!svn/bc/68796/trunk/devel/boost' path not found
    $ sudo svn co --revision 63323 http://svn.macports.org/repository/macports/trunk/dports/devel/boost/ Users/Shared/dports/devel/boost/
    A Users/Shared/dports/devel/boost/files
    A Users/Shared/dports/devel/boost/files/libs-random-build-Jamfile.v2
    A Users/Shared/dports/devel/boost/files/patch-boost-iostreams-device-mapped_file.hpp.diff
    A Users/Shared/dports/devel/boost/files/patch-libs-mpi-build-Jamfile.v2.diff
    A Users/Shared/dports/devel/boost/files/patch-libs-random-random_device.cpp.diff
    A Users/Shared/dports/devel/boost/files/patch-tools-build-v2-tools-python.jam.diff
    A Users/Shared/dports/devel/boost/Portfile
    Checked out revision 63323.
    $ sync
    $ sudo portindex /Users/Shared/dports
    Creating port index in /Users/Shared/dports

    Total number of ports parsed: 0
    Ports successfully parsed: 0
    Ports failed: 0
    Up-to-date ports skipped: 1

    $

    Mouse said...

    In short, I could not downgrade Boost from 1.42.0 to 1.41.0 in Macports, as the previous poster suggested. It just did not work.

    So instead I chose to patch "encfs", truncating that "V6SubVersion" from release date (now who cares for that date, really?) to something more palatable to Boost, like a small nice round number 16.

    I've installed encfs via Macports, got the standard problem of inability to re-mount directories, and addressed it in the following way:

    0. sudo port uninstall encfs

    1. Edited encfs/FileUtils.cpp file and created "diff -u encfs/FileUtils.cpp.orig encfs/FileUtils.cpp"

    2. Named this patch file "patch-encfs-FileUtils.cpp.diff" and copied it to
    /opt/local/var/macports/sources/rsync.macports.org/release/ports/fuse/encfs/files
    directory.

    3. Added the following line to file
    /opt/local/var/macports/sources/rsync.macports.org/release/ports/fuse/encfs/Portfile

    patchfiles patch-encfs-FileUtils.cpp.diff

    4. sudo port install encfs

    From this point on, encfs works fine. Caveat: I don't have directories protected by onder version of encfs - so I don't need compatibility with V5SubVersion, etc. Those who do need that compatibility probably have to wait till Boost will be fixed - if Boost maintainers would agree to revert.

    Unknown said...

    My apologies, Mouse (and everyone else!)

    I left out a key step to downgrading macports using a procedure I adapted from here: http://tinyurl.com/28sjaje

    As step 2 of my procedure (after the mkdir /Users/Shared/dports) to any of the steps in my comment, do the following:

    Edit /opt/local/etc/macports/sources.conf using any text editor (nano, vi, mate) and add the created repository before the rsync url:
    file:///Users/Shared/dports

    This will enable the rest of the procedure to work; without it macports will not see your manually created repository.

    Apologies again, and thanks, mouse for the creative alternative solution!

    D

    Mouse said...
    This comment has been removed by the author.
    Mouse said...
    This comment has been removed by the author.
    Mouse said...

    Regarding backing up (say via Time machine) home directories protected by FileVault - see these:

    http://macosx.com/article/live-filevaultsparse-bundle-backups-in-leopard.html

    http://www.mymacosx.com/snow-leopard/time-machine-backup-filevault.html

    http://blog.eurocomp.info/2009/12/12/how-to-time-machine-and-file-vault-the-real-thing-also-works-with-snow-leopard/

    I recommend combining the approaches outlined in the last two URLs, as you need both IncludedVolumes and IncludedVolumeUUIDs in order for Time machine to pick the FileVault directory up.

    Mouse said...

    Oh, and for TrueCrypt - it's next to useless on Mac, IMHO. Very limited support, and very limited capabilities - e.g. creating filesystems (unless you enjoy FAT32). Lord knows I tried.

    On Windows or between Windows and Linux - probably OK, looked good. But not on Mac.

    Anonymous said...

    The big problem of this approach is that basically user's preferences in ~/Library/Preferences are read before login hook is executed, so no way to localy change them - like screen saver password protection, or login at startup items.

    These will never be read from encrypted preferences file before EncFS home folder get's mounted.

    Very courius how other coped with that.

    This is my script for login hook:

    MINE:~ ent$ sudo defaults read com.apple.loginwindow
    {
    LoginHook = "/Library/Management/loginhook.sh";
    LogoutHook = "/Library/Management/logouthook.sh";
    }

    #!/bin/bash
    PASS=$(security find-generic-password -ga EncFS 2>&1 >/dev/null | cut -d'"' -f2)
    RAW="/Users/.$1"
    MOUNTPOINT="/Users/$1"

    echo $PASS | sudo -u $1 /usr/local/bin/encfs -S $RAW $MOUNTPOINT


    Regards,
    Krzysztof

    G. Lloyd said...

    Thanks for taking the time to write the post. I'm using Lion, and it looks like I'm the first to post here about your solution in 10.7 (10.7.2). I'm hoping you might be able to point me in the right direction.

    I essentially have two problems:

    1. Executing the su command and passing the password from the keychain does not work unless I completely remove su from the process. If I simply use the following it works like a charm:

    security find-generic-password -ga EncFS 2>&1 >/dev/null | cut -d'"' -f2 | sudo -u greg /usr/local/bin/encfs -S /Users/greg/Dropbox/BoxCrypt /Users/greg/Desktop/DropBox

    2. My other problem is that the above command works at the command line, but does not work as a login hook. I'm not Unix savvy enough to know if the reason is that the directories you list are not found in the exact same location (example - usr/local/sbin does not exist, but usr/local/bin does). In my paste above you can see that I have compensated for it. Regardless, I follow the instructions for adding the login hook and logout hook to no avail. It just appears as nothing happens at all at login. I can't find anything in the Console stating that there was an issue with the login hook or EncFS, either.

    I have had success executing the loginhook script as a login item, but it's messy as it open and leaves the Terminal window open after login.

    Any thoughts? Is this perhaps a Lion issue?

    Thanks again for the post!

    G. Lloyd said...

    Let me add, running the following command in the Terminal:

    su - l greg -c "security find-generic-password -ga EncFS" 2>&1 >/dev/null | cut -d'"' -f2 | sudo -u greg /usr/local/bin/encfs -S /Users/greg/Dropbox/BoxCrypt /Users/greg/Desktop/DropBox

    Produces a blank line beneath the command, as if it's awaiting further input. If I hit enter I receive no feedback from the Terminal. If I type in the correct password for the volume I receive no feedback from the Terminal. If I hit Cntrl-C I receive:

    Error decoding volume key, password incorrect.

    Any ideas on the matter are appreciated.

    G. Lloyd said...

    To anyone interested, I believe I figured out what went wrong: SU no longer works as it did prior to Lion. Using the account's nickname, in this case "greg", was not suffice to SU. It wanted the full name, "Gregory Lloyd". Where the following command would *not* work:

    su - greg -c "security find-generic-password -ga EncFS" 2>&1 >/dev/null | cut -d'"' -f2 | sudo -u greg /usr/local/bin/encfs -S /Users/greg/Dropbox/BoxCrypt /Users/greg/Desktop/DropBox

    This command does work:

    su "Gregory Lloyd" -c "security find-generic-password -ga EncFS" 2>&1 >/dev/null | cut -d'"' -f2 | sudo -u greg /usr/local/bin/encfs -S /Users/greg/Dropbox/BoxCrypt /Users/greg/Desktop/DropBox

    Notice that sudo has no problem with "greg" over "Gregory Lloyd".

    My problem now is the same as Olaf's - I am challenged for the Keychain password at login, even though I have instructed Keychain to "Always Allow" for the application "security." So I have avoided entering the EncFS password to mount my encrypted volume, only to have to enter my password for approval in Keychain.

    G. Lloyd said...

    Man - I'm burning up your page. I at least hope this is helpful to others.

    I've found that I was wrong about having to invoke the user's name using "Gregory Lloyd" instead of "greg." The problem is in the -l switch of the SU command. It appears to just not invoke the user's account, causing the return of a blank password from the Keychain.

    Not using the -l option means that I'm running the command as someone other than the user "greg," which is what I believe causes the request to enter the keychain password.

    So I'm chalking this up as a problem in Lion, which didn't exist in Leopard or Snow Leopard.