ecryptfs-utils private directory should support translations of "Private"

Bug #247421 reported by Dustin Kirkland 
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
eCryptfs
Fix Released
Undecided
Dustin Kirkland 
ecryptfs-utils (Ubuntu)
Fix Released
Wishlist
Dustin Kirkland 

Bug Description

Binary package hint: ecryptfs-utils

At https://wiki.ubuntu.com/EncryptedPrivateDirectory
Milan71 wrote:
"I'd like to know whether you've thought about a way of translating the name of this directory? It would be good if this 'Private' dir was included in the XDG User Dirs specification, since it is a common use case. But waiting for this, you may need something like a patch for xdg-user-dirs update to achieve this."

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

I absolutely want to support translations of the "Private" directory name, and it's definitely on my agenda.

This is a little bit complex at the moment. I have painstakingly created a setuid binary, mount.encrypted_private, that allows non-privileged users to mount their encrypted private directory. In order to pass the multiple levels of audits required to enable such a powerful setuid utility, I had to hardcode a couple of things.

Namely, the algorithm (aes), the key bytes (16), and the directory names ($HOME/.Private and $HOME/Private). My intention is to make each of these 3 parameters configurable by the system administrator in a /etc/ecryptfs.conf (perm 644) file. The key is that we cannot allow the user to arbitrarily choose the name of the directory in order to prevent a multitude of vulnerabilities.

:-Dustin

Changed in ecryptfs-utils:
assignee: nobody → kirkland
importance: Undecided → Wishlist
status: New → Triaged
Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

But a system-wide folder name would not suit the needs, since it is a basic Unix principle that all users on a system may not use the same language. Locale is strictly per-user, and moreover it can change over time. That's why something based on xdg-user-dirs is IMHO the way to go. This ~/Private folder is just like another standard foler, just like ~/Desktop or ~/Music.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

The mount.ecryptfs_utils utility is a setuid binary.

Unfortunately, malicious users can do some really nasty things to a system if non-privileged users are allowed to arbitrarily choose the mount point.

I would gladly review and endorse patches, if anyone has a workable, secure solution....

:-Dustin

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

I'll look at xdg-user-dirs just as soon as I get a chance.

I think the problem really boils down to keeping non-privileged users from arbitrarily choosing the directory name. That *must* be controlled by the system administrator. Perhaps the sysadmin or the package can provide a whitelisted set of choices. I think something like that will work.

:-Dustin

Revision history for this message
Michael Bryant (leachim) wrote :

Could you not have something like
.Private-encrypted holding the encrypted versions
.Private holding the unencrypted versions / the symlink
then Private or the translated version being a symlink to the hidden .Private?

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Mike-

I think something like that might actually work ;-)

I'll work on this some more once 8.10 is out of the door.

Thanks.
:-Dustin

Revision history for this message
Nicolò Chieffo (yelo3) wrote :

I've had a simple look at the code.
grep showed these:

debian/patches/40-zero_out_grep_options.dpatch: PRIVATE_DIR="Private"
src/pam_ecryptfs/pam_ecryptfs.c:#define PRIVATE_DIR "Private"
src/utils/ecryptfs-setup-private:PRIVATE_DIR="Private"
src/utils/mount.ecryptfs_private.c:#define PRIVATE_DIR "Private"
src/utils/ecryptfs-umount-private:PRIVATE_DIR="Private"
src/utils/ecryptfs-mount-private:PRIVATE_DIR="Private"

from bash scripts you can get an xdg dir using the bash script "xdg-user-dir PRIVATE" (after having set it into .config/user-dirs.dirs)
and in the 2 .c files you can change the macro to g_get_user_special_dir (G_USER_DIRECTORY_PRIVATE), after patching glib to add the new directory.

Revision history for this message
sebastian-s (sebastian-s) wrote :

Are there other areas which need translation? the translation page in LP is not available.

Revision history for this message
Tuomas Aavikko (taavikko) wrote :

Sidenote from user who's using Finnish language-pack(s)

Name: Private, doesn't fit in overall translations, and breaks up the overall experience.

XDG_DESKTOP_DIR="$HOME/Työpöytä"
XDG_DOWNLOAD_DIR="$HOME/Työpöytä"
XDG_TEMPLATES_DIR="$HOME/Mallit"
XDG_PUBLICSHARE_DIR="$HOME/Julkinen"
XDG_DOCUMENTS_DIR="$HOME/Asiakirjat"
XDG_MUSIC_DIR="$HOME/"
XDG_PICTURES_DIR="$HOME/Kuvat"
XDG_VIDEOS_DIR="$HOME/Videot"

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

This has been fixed upstream.

As of ecryptfs-utils-66, the user can choose their Private mountpoint by setting the path in the file ~/.ecryptfs/Private.mnt to whatever they want.

:-Dustin

Changed in ecryptfs:
assignee: nobody → kirkland
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (4.8 KiB)

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 <email address hidden> 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, ...

Read more...

Changed in ecryptfs-utils:
status: Triaged → Fix Released
Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Well, this is nice to have, thanks, but IMHO this does not fix the bug. Can you think of any standard user that will go and edit this file to get his Private folder translated?! Doing so manually is nonsense.

What we need is a kind of extension to xdg-user-dirs so that the dir name is translated by default, and that if you change language, folder names are changed accordingly. This could be achieved with a little patch to the xdg-user-dirs code, specific to Ubuntu.

This is really required, because else ecryptfs-utils will be the only program on the Desktop to introduce untranslatable strings, leading to poor user experience. It would be a shame given that this program is such a great piece of work!

Revision history for this message
Ricardo Pérez López (ricardo) wrote :

I totally agree with Milan. The *real* fix must be to use xdg-user-dirs (or something similar), so the folder name was already translated since you installed Ubuntu.

Revision history for this message
sebastian-s (sebastian-s) wrote :

another step in between could be some sort of wizard who knows about the translation and does the changes to ~/.ecryptfs/Private.mnt

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.