Skip to content

Truecrypt hackery

I don't really like TrueCrypt. But it's the quasi standard to encrypt (external) storage which is to be attached to different operating systems. Yes, its license is kinda fishy; OSI approval has been withdrawn too. But after all, TrueCrypt is available for Windows, MacOS X and GNU/Linux (x86). And lacking the skillz to write my own halfway-portable encryption wrapper myself, I'm stuck with it. That being said, there's still the quest for the optimal filesystem: I'd need a POSIX like filesystem, providing symlinks, honoring ownerships and permissions and perhaps with journaling on top. And I need read and write support.

Let's see:
  • FAT - not a chance
  • NTFS - crappy symlink implementation, no (stable) MacOS driver
  • UFS - it's dead, Jim. Also: no stable write support in the Linux kernel.
  • ZFS - almost! It's even included in MacOS 10.5, but only as a read-only version. There's a ZFS project on macosforge.org, but it lists MacOS 10.5 as a requirement and I'm still on 10.4 on my PowerBook :-\
  • HFS+ - well, that's it I guess. Comes with all the features required, write support under Linux is pretty stable, not sure about journaling support under Linux though.
  • Anyway, the real question was: how do I convince Truecrypt to format my new volume as HFS+, but with journal, case-sensitivity and enabled ownerships?

    Here it is:
  • Create a new volume in TrueCrypt, just choose "none" when it wants to format your volume. Actually, it does not matter, as we're gonna reformat anyway.
  • Use Truecrypt to "mount" the volume, but before doing that click "Options" in the mount-dialog and check "do not mount" - the wording is kinda sucky, yes.
  • Now TrueCrypt should have activated your volume, but not mounted. We'll now format (and partition) our activated device:
  • $ diskutil disk6
    /dev/disk6
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:                            disk6                  *931.2 Gi   disk6
    
    $ diskutil partitionDisk disk6 1 GPTFormat "Case-sensitive Journaled HFS+" disk6 100%
    Started partitioning on disk disk6 disk6
    Creating partition map
    Formatting disk6s2 as Mac OS Extended (Case-sensitive, Journaled) with name disk6
    [ + 0%..10%..20%..30%..40%..50%..60%..70%..80%..90%..100% ] 
    Finished partitioning on disk disk6
    /dev/disk6
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *931.2 Gi   disk6
       1:                        EFI                         200.0 Mi   disk6s1
       2:                  Apple_HFS disk6                   930.9 Gi   disk6s2
    $ diskutil rename /dev/disk6s2 disk6s2
    $ diskutil list disk6
    /dev/disk6
       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *931.2 Gi   disk6
       1:                        EFI                         200.0 Mi   disk6s1
       2:                  Apple_HFS disk6s2                 930.9 Gi   disk6s2
    
    We can now deactivate the device with TrueCrypt ("unmount") and mount it again - this time for real. We still have to enable the ownership model though:
    $ vsdbutil -c /Volumes/disk6s2 
    No entry found for '/Volumes/disk6s2'.
    $ vsdbutil -a /Volumes/disk6s2
    $ vsdbutil -c /Volumes/disk6s2
    Permissions on '/Volumes/disk6s2' are enabled.
    
    $ diskutil info disk6s2
    [...]
       Device Identifier:        disk6s2
       Device Node:              /dev/disk6s2
       Mount Point:              /Volumes/disk6s2
       File System:              Case-sensitive Journaled HFS+
                                 Journal size 81920 KB at offset 0x1d19000
       Owners:                   Enabled
       Partition Type:           Apple_HFS
    
    Now we can really start using it. I still wonder why TrueCrypt (or MacOS X) defaults to case-insensitivity and does not enable the ownership model by itself.

    /etc/release

    I just found out which package takes care of the /etc/release file: it's SUNWsolnm*. So, this file actually will get updated when a new release comes by.
    $ cat /etc/release 
                          Solaris 10 10/08 s10s_u6wos_07b SPARC
               Copyright 2008 Sun Microsystems, Inc.  All Rights Reserved.
                            Use is subject to license terms.
                                Assembled 27 October 2008
    
    * SunSolve account needed

    sharemgr.exe not found

    I feel kinda stupid even asking this, having done this for years now, but: how do you create NFS shares on a Solaris 10 system? /etc/exports is obsolete, but so is dfstab(4), apparently:
          Do not modify this file directly. This file is reconstructed and only 
          maintained  for backwards compatibility. Configuration lines could
          be lost. Use the sharemgr(1M) command for all share management.
    
    However, sharemgr(1m) does not seem to exist on this Solaris10 box. Well, sharemgr has been introduced in late 2006 (in response to Bug#6281048) but this nifty tool hasn't made it to Solaris10 yet.

    So, for now we're stuck with:
  • editing /etc/dfs/dfstab or
  • using zfs set sharenfs, for ZFS filesystems.

  • There are nice articles from Doug McCallum on this topic:
  • Share properties under sharemgr
  • sharemgr and ZFS
  • ggrep --devices=skip

    Every now and then I'd like to (recursively) search for patterns in a directory tree. Since Solaris' grep(1) does not understand -r, I used SUNWggrep. But grep'ing through e.g. /etc never seems to come to an end, and truss(1) knows why:
    $ /usr/sfw/bin/ggrep --version | head -1
    grep (GNU grep) 2.5
    $ truss -elfda /usr/sfw/bin/ggrep -D skip -r foo /etc
    [...] 
    8341/1:          0.0448 open64("/etc/cron.d/FIFO", O_RDONLY)            = 3
    8341/1:          0.0454 fstat64(3, 0xFFBFFA78)                          = 0
    8341/1:         read(3, 0x00044000, 32768)      (sleeping...)
    
    Well, I won't comment on the fact that we have devices in /etc at all, but I explicitly told grep to skip devices. Apparently this option is just being ignored. Using the latest GNU/grep CVS checkout does help and the changelog does indeed mention a fix for the --devices option.

    Oh, of course: this could be done with find too, but GNU/grep is so much easier than:
    $ find /etc -type f -exec grep foo '{}' +
    
    Hint: add "-D skip" to your GREP_OPTIONS environment variable, that way it's passed to GNU/grep automatically.

    Update: a careful reader noticed that I confused SUNWggrep and SMCgrep - I did indeed and corrected it, finally. Thanks for the hint! For the record, the current version of SMCgrep does NOT have this problem, it's all good! :-)

    binding cherokee to a single network address

    Well, this is my first attempt with Cherokee and I thought server!listen was a valid configuration key. However, the latest GIT checkout gave:
    $ /opt/cherokee/sbin/cherokee -C ./cherokee.conf 
    ERROR: Server parser: Unknown key "listen"
    Couldn't read the config file: ./cherokee.conf
    
    This has been reported already and is said to be fixed with changeset 2766, so why is this still happening?

    Update: As an observing reader pointed out, the correct key is named server!bind!1!interface now. The changelog is rather quiet about this, but searching in the commits reveals that this change has been made last year already, though the documentation still mentions server!listen.

    Fedora: which which

    Oh, come on, Fedora 11, a base install with no X11 contains almost 1000 packages but you don't have "which"? Better yet, you have an extra package for this? Wow:
    $ yum info which
    [...]
    Name       : which
    Arch       : i586
    Version    : 2.19
    Release    : 4.fc11
    Size       : 40 k
    Summary    : Displays where a particular program in your path is located
    
    Something like "fedorautils" might help, hm?
    $ dpkg -S `which which`
    debianutils: /usr/bin/which
    
    Oh, and while we're at it: here's how to get httpd running on a different port:
    # service httpd start
    Starting httpd: (13)Permission denied: make_sock:
    could not bind to address 192.168.10.104:1080
    no listening sockets available, shutting down
    Unable to open logs                                    [FAILED]
    
    # tail /var/log/audit/audit.log
    [...]
    type=AVC msg=audit(1242447992.170:51): avc:  denied  { name_bind } for  pid=6144 \
    comm="httpd" src=1080 scontext=unconfined_u:system_r:httpd_t:s0 \
    tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
    
    # /usr/sbin/semanage port -a -t http_port_t -p tcp 1080
    # service httpd start
    Starting httpd:                                          [  OK  ]
    
    A detailled explanation can be found in the Fedora SELinux User Guide.
    Note: semanage comes with the policycoreutils-python package.

    Rainforest Schmainforest

    After stumbling over yet another celebritiy to speak out about the (dying of our) precious rainforests, I just couldn't help myself and wanted to see if the numbers add up. I'm talking about the rate at which the rainforests are destroyed, as they rank from "the size of a football" field every second or every four seconds.

    A standard football pitch is about 7000 sqm in size. The size of the rainforest was much harder to come by, the number I have now is 2.6 million square miles or 6.73*10^12 sqm. Well, by that rate we should be out of trees in 122 years resp. 30 years with the more scarier number. Still, wouldn't that be just enough time to plant new trees as they are cutting them down? Then again, I don't know jack about envrionmental issues, but this play on numbers got me curious :-\