ecryptfs-recover-private option --rw prevents recognition of directory parameter

Bug #1004082 reported by Karl-Philipp Richter
30
This bug affects 6 people
Affects Status Importance Assigned to Milestone
eCryptfs
Fix Released
Low
Tyler Hicks

Bug Description

If I specify the --rw option and pass an encrypted directory as parameter ecryptfs-recover-private starts to search in the whole fs although it doesn't have to/shouldn't.
<code>sudo ecryptfs-recover-private ~/.Private</code> prompts "Try to recover this directory? [Y/n]:" immediately, whether <code>sudo ecryptfs-recover-private --rw ~/.Private</code> starts to search the file system.
Version of ecryptfs-utils is 96-0ubuntu3 running on Ubuntu 12.04.
ecryptfs-recover-private doesn't seem to have a possiblity to find out version.

description: updated
Revision history for this message
Wesley Wiedenmeier (magicalchicken-deactivatedaccount) wrote :

Confirmed, this only seems to happen when the command is typed like "ecryptfs-recover-private --rw /path/to/dir", but if the command is typed as "ecryptfs-recover-private /path/to/dir --rw" then it uses the specified directory as it should. This makes me think that it is something wrong with how command line arguments are parsed.

Changed in ecryptfs:
status: New → Confirmed
Revision history for this message
NoOp (glgxg) wrote :

Confirmed:

$ apt-cache policy ecryptfs-utils
ecryptfs-utils:
  Installed: 87-0ubuntu1.3
  Candidate: 87-0ubuntu1.3
  Version table:
 *** 87-0ubuntu1.3 0
        500 http://archive.ubuntu.com/ubuntu/ natty-updates/main i386 Packages
        100 /var/lib/dpkg/status
     87-0ubuntu1.2 0
        500 http://security.ubuntu.com/ubuntu/ natty-security/main i386 Packages
     87-0ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ natty/main i386 Packages

Revision history for this message
T. Middleton (timtoo) wrote :

The logic of the code currently is:

- if the first argument is a directory ignore all other arguments continue
- otherwise search the entire system for .Private directories, and then check if the first argument was --rw

In all cases only the first command line argument is checked.

Revision history for this message
Patrick Pleneficsh (byteit101) wrote :

I recently came across this bug, and it appears the fix is fairly trivial and consists of two parts:

#1. Move the --rw detection before the directory detection. rw is now always correctly detected
#2. Add a elif clause to detect if the second argument is a folder, but not the first, as is likely the case when the --rw flag is passed in. if it is, the shift the arguments, and do the same as the first if statement (ie. set the dirs variable)

Attached is my patch

Revision history for this message
Tyler Hicks (tyhicks) wrote :

Thanks for tracking down the problem, timtoo, and thanks for the patch, Patrick.

What I ended up committing was just slightly different than Patrick's patch.

Changed in ecryptfs:
assignee: nobody → Tyler Hicks (tyhicks)
importance: Undecided → Low
status: Confirmed → Fix Committed
Revision history for this message
Bertrand G (berteh) wrote :

please release fixed version... it's still not in 12.04 repository.
thanks.

Revision history for this message
NoOp (glgxg) wrote :

Bertrand, I installed Dustin's PPA:
<https://launchpad.net/~ecryptfs/+archive/ppa>
eCryptfs PPA
  “eCryptfs” team eCryptfs PPA
on 12.04 and it's working for me. You might want to give that a try.

Revision history for this message
NoOp (glgxg) wrote : Re: [Bug 1004082] Re: ecryptfs-recover-private option --rw prevents recognition of directory parameter

On 12/30/2013 04:30 PM, NoOp wrote:
> Bertrand, I installed Dustin's PPA:
> <https://launchpad.net/~ecryptfs/+archive/ppa>
> eCryptfs PPA
> “eCryptfs” team eCryptfs PPA
> on 12.04 and it's working for me. You might want to give that a try.
>

Scratch that. I had to purge the ppa in order to have the /home folder
decrypt on boot.

Revision history for this message
NoOp (glgxg) wrote :

Tyler: when can we expect this to be fixed for 12.04?

Changed in ecryptfs:
status: Fix Committed → Fix Released
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.