ecryptfs team mailing list archive

[Launchpad Bug Tracker <294888@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package ecryptfs-utils - 66-2ubuntu1

---------------
ecryptfs-utils (66-2ubuntu1) jaunty; urgency=low

  * Merge from debian unstable,
    (LP: #259631, #293433, #286265, #247421, #294888, #298421)
  * Remaining changes:
    - debian/ecryptfs-utils.postinst: handle pam-auth-update (Bug: #506172)
    - debian/rules:
      + keep the dpatch infrastructure around, as we'll likely
        need it again at some point soon
      + install the desktop, readme, and pam-auth-update files ()
    - debian/ecryptfs-utils.install: install the desktop, readme shared files
      (Bug: #506172)
    - debian/control:
      + keep the dpatch build dep
      + depend on libpam-runtime (Bug: #506172)
    - debian/ecryptfs-utils.prerm: remove pam-auth-update configuration
      (Bug: #506172)
    - debian/ecryptfs-mount-private.txt: readme to install in unmounted
      private dir (Bug: #506172)
    - debian/ecryptfs-mount-private.desktop: desktop link to install in
      unmounted private dir (Bug: #506172)
    - debian/ecryptfs-utils.dirs: usr share install dirs (Bug: #506172)
    - debian/ecryptfs-utils.pam-auth-update: pam stack configuration
      (Bug: #506172)

ecryptfs-utils (66-2) unstable; urgency=low

  * Removing auth-client-config support, no longer used.
  * Adding ecryptfs-utils recommends to keyutils.
  * Building without ssl, ecryptfs_key_mod_openssl.c has incompatible
    license (GPL-2+).
  * Building without pkcs11 helper, ecryptfs_key_mod_pkcs11_helper.c
    links against openssl and has incompatible license (GPL-2+).
  * Building without pkcs11 helper, ecryptfs_key_mod_tspi.c links
    against openssl and has incompatible license (GPL-2+).

ecryptfs-utils (66-1) unstable; urgency=low

  * Manually adding second line of the commit message when merging
    upstream version 65 to changelog.
  * Merging upstream version 66.
  * Adding ecryptfs-utils.postinst to create /var/lib/ecryptfs on
    package installation time.

ecryptfs-utils (65-1) unstable; urgency=low

  * Merging upstream version 65:
    - Adds --wrapping option to ecryptfs-setup-private command to use an
      independent wrapping passphrase, different from the login passphrase
      (Closes: #505008).
  * Removing pam-doc.dpatch, went upstream.
  * Adding build-depends to swig.
  * Adding build-depends to python-dev.
  * Including python bindings in libecryptfs0.

ecryptfs-utils (64-3) unstable; urgency=low

  * Replacing obsolete dh_clean -k with dh_prep.
  * Adding patch from Osamu Aoki <osamu@xxxxxxxxxx> to update
    ecryptfs-pam-doc.txt contents with s/Confidential/Private/
    (Closes: #504934).
  * Updating homepage and download location in control and copyright
    (Closes: #504930).
  * Updating author information in copyright.
  * Installing desktop shortcut and readme to /usr/share/ecryptfs-utils.
    Together with the fixes of upstream version 64, this interactively prompts
    for passwords now (Closes: #504370).

ecryptfs-utils (64-2) unstable; urgency=low

  * Adding build-depends to python (Closes: #504719).

ecryptfs-utils (64-1) unstable; urgency=low

  * Removing sbin-path.dpatch, not needed anymore.
  * Building with --enable-static, was default previously.

ecryptfs-utils (63-1) unstable; urgency=low

  * Merging upstream version 63.

ecryptfs-utils (61-1) unstable; urgency=low

  * Using patch-stamp rather than patch in rules file.
  * Merging upstream version 61.
  * Rediffing sbin-path.dpatch.

ecryptfs-utils (58-2) unstable; urgency=low

  * Adding patch from situert <situert@xxxxxxxxx> to call ecryptfs
    helper scripts in /sbin with full path to avoid problem if /sbin is
    not in PATH (Closes: #498543).

ecryptfs-utils (58-1) unstable; urgency=low

  * Merging upstream version 58.

ecryptfs-utils (57-1) unstable; urgency=low

  * Updating vcs fields in control file.
  * Merging upstream version 57.

ecryptfs-utils (56-1) unstable; urgency=low

  * Setting permissions for ecryptfs.acc when installing it in rules.
  * Merging upstream version 56.

ecryptfs-utils (55-1) unstable; urgency=low

  * Merging upstream version 55.

ecryptfs-utils (53-2) unstable; urgency=low

  * Adding auth-client-config support, thanks to Dustin Kirkland
    <kirkland@xxxxxxxxxx>.

ecryptfs-utils (53-1ubuntu13) intrepid-proposed; urgency=low

  Fixes for LP: #259631, add interactive mounting capability
  * debian/rules, debian/ecryptfs-utils.dirs,
    debian/ecryptfs-utils.install, debian/ecryptfs-mount-private.desktop,
    debian/ecryptfs-mount-private.txt: install the new desktop shortcut
    file and readme.txt to /usr/share/ecryptfs-utils
  * debian/patches/60_interactive_mount.dpatch: modify ecryptfs-mount-private
    utility to interactively prompt for password
  * debian/patches/00list: updated accordingly

 -- Dustin Kirkland <kirkland@xxxxxxxxxx>   Tue, 18 Nov 2008 19:06:54
-0600

** Changed in: ecryptfs-utils (Ubuntu)
       Status: New => Fix Released

-- 
Cannot specify location of Private directory
https://bugs.launchpad.net/bugs/294888
You received this bug notification because you are a member of eCryptfs,
which is subscribed to ecryptfs-utils in ubuntu.

Status in eCryptfs - Enterprise Cryptographic Filesystem: Fix Released
Status in “ecryptfs-utils” source package in Ubuntu: Fix Released

Bug description:
Binary package hint: ecryptfs-utils

There doesn't appear to be anyway to set up the Private directory in any location other than ~/Private.  The use case here is that to support suspend/hibernate, I've put my /home on the tiny 4Gb partition on my EEE 701 netboot.  However, I then symlink all my directories in Home (such Pictures, Videos, Music, etc) to a 32Gb SD card which is mounted as /media/MyData.  I'd like to put the encrypted directory on that card and not on /home.

I've tried creating a symlink called Data inside ~/Private to a directory on my card.  However, when I created a text file by editing ~/Private/Data/test.txt, then running /sbin/umount.ecryptfs_private, I was dismayed to discover that the text file was written to my media card unencrypted.  This doesn't appear to be a solution.

I also tried symlinking ~/.Private to a directory on the media card then re-running ecryptfs-setup-private, but sadly it complains that .Private is not empty (although it is, hidden files and all) and fails to complete the process.

My lack of fundamental understanding of ecryptfs is clearly a barrier here, but perhaps someone more knowledgeable than I can find a solution.  This bug is opened in the spirit that this should be an option in the ecryptfs-setup-private process, rather than finding a hack that makes the change after the fact.