ecryptfs Private directory not mounted after changing password in users-admin

Bug #307019 reported by komputes
60
This bug affects 16 people
Affects Status Importance Assigned to Milestone
gnome-control-center (Ubuntu)
Fix Released
High
Unassigned
gnome-system-tools (Ubuntu)
Fix Released
High
Unassigned
liboobs (Ubuntu)
Invalid
Undecided
Unassigned
system-tools-backends (Ubuntu)
Fix Released
High
Unassigned

Bug Description

I'm running Jaunty Alpha 1, and I had a ecryptfs protected Private directory in home directory. I changed my system password using users-admin (System > Administration > Users and Groups), this caused the Private directory not to be mounted. When I ran ecryptfs-mount-private, the new password was not accepted, the old password was accepted and the Private directory was mounted.

This may be because users-admin is using usermod rather than passwd, and that usermod unconditionally changes a password.

komputes (komputes)
Changed in gnome-system-tools:
status: New → Confirmed
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Subscribed Kees, added liboobs, as he indicated the bug is actually in this (buggy) library.

I'm attaching a screenshot to demonstrate the problem. This Users-and-Groups diaglog exposes a mechanism to administrative users to reset a password. Note that it's not prompting for the user's current password. This makes ecryptfs re-wrapping of the passphrase impossible. Lose. In this situation, the user's system passphrase will be changed to the new passphrase, but the user's ~/.ecryptfs/wrapped-passphrase file will still be wrapped with the previous passphrase.

:-Dustin

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

Attaching a second screen shot of the "proper" way for a user to change their password graphically, using System->Preferences->About Me.

From the command line, one should use "passwd".

The problem really occurs when the Administrative user forcefully changes another user's password (or their own), without passing the user's current password to PAM.

:-Dustin

Revision history for this message
Jarno Suni (jarnos) wrote :

I don't see that "About me" dialog in Xubuntu Jaunty, but "passwd" can be used, of course.

Revision history for this message
komputes (komputes) wrote :

Jarno, Thus bug only affects users-admin which is a gnome system utility. You do not need to worry if using XFCE, and yes passwd works (and is a current workaround to this bug) but very rarely do new users use command line tools.

Revision history for this message
Jarno Suni (jarnos) wrote :

Well, Xubuntu has both Xfce and users-admin (gnome-system-tools is in recommends of xubuntu-desktop.)

Changed in liboobs (Ubuntu):
importance: Undecided → Low
Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Hi Pedro-

I'm confirming this bug, and moving it to "High". This is extremely bad functionality, and I think should be a High priority.

Thanks,
:-Dustin

Changed in liboobs (Ubuntu):
status: New → Confirmed
importance: Low → High
Changed in gnome-system-tools (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Dustin: I agree that this bug should absolutely be fixed, and the system-tools-backends provide a good framework for doing that quite easily. I'm OK to help if you provide me with the required commands we should run when changing password. Then we could hack a patch to do that when running Ubuntu >= 9.04.

Revision history for this message
Kees Cook (kees) wrote :

Milan: unfortunately, g-s-t and liboobs is a very very broken framework. It needs to be replaced with something that uses PAM, like all the other proper user/group tools. :(

Changed in liboobs (Ubuntu):
status: Confirmed → Invalid
Changed in gnome-system-tools (Ubuntu):
status: Invalid → Confirmed
importance: Undecided → High
Changed in liboobs (Ubuntu):
importance: High → Undecided
status: Invalid → Won't Fix
Changed in gnome-system-tools (Ubuntu):
milestone: none → karmic-alpha-6
assignee: nobody → James Westby (james-w)
Revision history for this message
Kees Cook (kees) wrote :

As a limited work-around, the g-s-t user tab for one's own password should have a button to launch the "About Me" dialog, instead of the regular password-changing fields.

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

I can't let you say this kind of horror! ;-)

Being the new maintainer of the stb, gst and friends, I must precise that if you want them to work properly with a new feature, that's a matter of one line fixes, most of the time. They are actually using "usermod -p" in the background. So if you find the stb are broken, well, fix your command line tools. It would be fairly easy to use another program, or to run, say, ecryptfs-rewrap-passphrase, just after changing the password.

Do you know how About Me is working now? Adding a button to show gnome-about-me form users-admin is a completely mad alternative, given that the framework is actually working well and is waiting for us.

Changed in system-tools-backends (Ubuntu):
status: New → Confirmed
assignee: nobody → James Westby (james-w)
Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Merely keeping the gst task for searching purposes. The real work has to be done in the stb.

Changed in liboobs (Ubuntu):
status: Won't Fix → Invalid
Revision history for this message
James Westby (james-w) wrote :

> Being the new maintainer of the stb, gst and friends,

Thanks for taking on this task.

> I must precise that if you want them to work properly with a new feature, that's a matter of one line fixes, most of
> the time. They are actually using "usermod -p" in the background. So if you find the stb are broken, well, fix your
> command line tools.

We can't fix "usermod -p" to go through pam, as pam requires the plaintext password so that the
modules can do as they like with it (which ecryptfs needs I believe). usermod -p takes the encrypted
password.

It does this as the separation between gst and stb means that you want to crypt the password in one
process and then pass it over, rather than sending the plaintext. This separation is needed for the
policykit stuff, and it is chosen to do it over DBus.

When changing your own password you don't need polkit, and so you can do it in process (as
gnome-about-me does), and so use pam with the plaintext password.

Now, Kees' proposal for the common case of changing your own password is to hand off to
gnome-about-me, gst could do this in-process for the same effect.

So, to fix this properly in gst for the other cases we need to do something different. Some
ideas

  * Rely on DBus security policies to stop snooping. I'm not sure how reliable this is.
  * DBus-ssl: negotiate an encrypted channel using DH key exchange or similar over DBus. I like the idea but it's rather over-engineered unfortunately :-)
  * gst requests that stb create a named pipe on the fs that it then writes the plaintext to. Kees would be able to say how secure that would be.
  * Drop DBus and move to a suid helper, still protected by polkit, and pass the plaintext using stdin or similar.

Having something like the above would clearly be a better fix, but is more work than the proposed
simple fix for the common case.

> It would be fairly easy to use another program, or to run, say, ecryptfs-rewrap-passphrase, just
> after changing the password.

The backend still would need the plaintext to run that wouldn't it?

Thanks,

James

Revision history for this message
Kees Cook (kees) wrote :

Milan: sorry I can cam eoff harsh, we've just had a lot of technical problems with g-s-t and how it handles passwords. James detailed the primary problem. As an earlier work-around, we had to force it to correctly select the system's password hashing algorithm, which it had not been doing correctly either.

As to how to pass the clear-text password, I like the idea of pipes or fds, as those are well-prove and light-weight. negotiating SSL over dbus seems over-engineered for this situation. If permissions to the pipe can be correctly managed by stb, the named pipe for gst to write to (with the name passed over dbus?) seems like the best match for this?

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Yeah, I forgot that eCryptfs requires the real password to work. It also needs the old password BTW, so this will never work if the admin changes the password, since he's not likely to know the old one. Thus, I'm not sure it's worth using the backends at all. Ideally, D-Bus could provide us with a secure connection (why isn't that the case?); we could also use a pipe, should be possible but will require some work.

If your goal is to get this fixed for Alpha 6, better go with a client-side solution. Just patch the GUI to call the required program. Then, ask for the old password if the user edited the new one (maybe that's not required if the folder is unwrapped).

I'm planning to redesign the GUI in the next cycle, and I may well use something like the about-me dialog to change passwords, so that may help in the middle-term. In the long term, I'm not sure we really need to pass the clear password to the backends, since it would only be useful for eCryptfs, which does not fit in our authentication model since the admin needs the original password. I'd eventually go for a solution where eCryptfs is setuid so that anybody (here the GUI) can ask the user the old and change it if it's the right one. No need for other checks, I guess. If the admin changes the password on it own, eCryptfs should show a dialog on start asking for the old password so that it is then changed. Can you find something better?

PS about the gst: I can perfectly understand your anger against them - so do I. They suffer from many little bugs that plague our user experience. But I don't think the design is broken at all: the future seems to be PolicyKit over D-Bus, and then sending the password hashed is the best solution - until eCryptfs appears, where we have to adapt. I can't see how using PAM would really help, apart from this case.

Revision history for this message
James Westby (james-w) wrote : Re: [Bug 307019] Re: ecryptfs Private directory not mounted after changing password in users-admin

On Thu Aug 27 22:36:16 UTC 2009 Milan Bouchet-Valat wrote:
> Yeah, I forgot that eCryptfs requires the real password to work. It also
> needs the old password BTW, so this will never work if the admin changes
> the password, since he's not likely to know the old one. Thus, I'm not
> sure it's worth using the backends at all. Ideally, D-Bus could provide
> us with a secure connection (why isn't that the case?); we could also
> use a pipe, should be possible but will require some work.

Well, pam can provide enough to ecryptfs for it to do it's job, so going
through pam would buy us this, and much more as well.

I'm not sure about DBus, I think it can provide a connection with some
level of security, but I'm also leaning towards a pipe being the
best solution.

> If your goal is to get this fixed for Alpha 6, better go with a client-
> side solution. Just patch the GUI to call the required program.

That may be wise at this point.

> I'm planning to redesign the GUI in the next cycle, and I may well use
> something like the about-me dialog to change passwords, so that may help
> in the middle-term. In the long term, I'm not sure we really need to
> pass the clear password to the backends, since it would only be useful
> for eCryptfs, which does not fit in our authentication model since the
> admin needs the original password.

It's more than eCryptfs, it allows us to use pam, which is a neccessity
in my eyes, having more than one thing handling all this stuff is going
to keep causing problems.

> I'd eventually go for a solution
> where eCryptfs is setuid so that anybody (here the GUI) can ask the user
> the old and change it if it's the right one. No need for other checks, I
> guess. If the admin changes the password on it own, eCryptfs should show
> a dialog on start asking for the old password so that it is then
> changed. Can you find something better?

I'm pretty certain that If we just pass the new password to pam then it
can do the rest. I belive that using "sudo passwd <user>" doesn't break
eCryptfs.

Thanks,

James

Revision history for this message
Kees Cook (kees) wrote :

On Fri, Aug 28, 2009 at 01:33:11PM -0000, James Westby wrote:
> I'm pretty certain that If we just pass the new password to pam then it
> can do the rest. I belive that using "sudo passwd <user>" doesn't break
> eCryptfs.

Unfortunately, AFAIK, that does break it -- it must be the user themselves
calling "passwd" since then PAM will prompt for the old password to
pass through the PAM stack. eCryptfs (and potentially other things)
use it to decrypt the mount passphrase, and then re-encrypt it with the
new PAM password.

Revision history for this message
James Westby (james-w) wrote :

On Fri Aug 28 18:21:08 UTC 2009 Kees Cook wrote:
> On Fri, Aug 28, 2009 at 01:33:11PM -0000, James Westby wrote:
> > I'm pretty certain that If we just pass the new password to pam then it
> > can do the rest. I belive that using "sudo passwd <user>" doesn't break
> > eCryptfs.
>
> Unfortunately, AFAIK, that does break it -- it must be the user themselves
> calling "passwd" since then PAM will prompt for the old password to
> pass through the PAM stack. eCryptfs (and potentially other things)
> use it to decrypt the mount passphrase, and then re-encrypt it with the
> new PAM password.

Ah, my apologies.

So changing gst to use pam buys us nothing over just special casing the
current user?

Thanks,

James

Revision history for this message
Kees Cook (kees) wrote :

On Fri, Aug 28, 2009 at 07:20:00PM -0000, James Westby wrote:
> So changing gst to use pam buys us nothing over just special casing the
> current user?

Administrative changes of user passwords when the user has an eCryptfs
mount will remain bugged (this is an eCryptfs limitation). However, there
are other larger things that could be hooked to PAM (e.g. LDAP). gst would
still need to keep a special-case of using regular privs to change the
current user's password.

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

So as I said, we'd better go with the GUI-side (and Ubuntu specific, at this point in the cycle) fix, special-casing the current user. Using PAM could be interesting, but that would need a deeper rework (LDAP and friends) that we can't do now, and from what I can see, PAM's advantages (if any) would be in other fields than eCryptfs.

A much easier solution, and maybe not so ugly, would be to always present a dialog asking for both passwords on login, when unwrapping the private dir failed. As a temporary solution at least, that could do the trick.

Revision history for this message
James Westby (james-w) wrote :

I'm having trouble coming up with an elegant way to add the special
case for the user themselves.

Adding a button to use gnome-about-me seems the best way, but
asking gnome-about-me to just run the password changer isn't
currently possible, and not trivial to implement for me. We could
run the whole of gnome-about-me, but that obscures the password
change button. Running gnome-about-me instead of the whole
properties dialog also means you can't change groups and the like.

Due to the architecture of g-s-t et. al. I'm not sure how to re-use
what is there and just have the process change the password without
having the backend make the change as well.

Any assistance would be welcome.

Thanks,

James

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

If you're still aiming at Karmic, an elegant solution is not really possible IMO. I'd sheerly copy/paste the code from gnome-about-me for the password dialog. Then, you can just adapt it so that when changing the password of the current user (see OobsSelfConfig), we ask for the old one, and use gnome-about-me's code instead of committing a password change using the stb. Emptying the entries will be anough for that, since we just take these from user_settings_get_user_data(), and the backends don't change the password when we send them an empty one.

Sure, that's ugly, but I don't think you can expect a better design in that timeframe... If you need more details, please just ask.

Revision history for this message
Kees Cook (kees) wrote :

Here is a patch to call gnome-about-me pop the password dialog when launched with the --password argument.

Changed in gnome-control-center (Ubuntu):
status: New → In Progress
importance: Undecided → High
Changed in gnome-system-tools (Ubuntu):
milestone: karmic-alpha-6 → ubuntu-9.10-beta
Changed in gnome-control-center (Ubuntu):
milestone: none → ubuntu-9.10-beta
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-control-center - 1:2.28.0-0ubuntu2

---------------
gnome-control-center (1:2.28.0-0ubuntu2) karmic; urgency=low

  * Add 98_password_dialog_launcher.patch: create a way to launch
    the password changing dialog externally (LP: #307019).

 -- Kees Cook <email address hidden> Tue, 22 Sep 2009 16:27:55 -0700

Changed in gnome-control-center (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-system-tools - 2.28.1-0ubuntu2

---------------
gnome-system-tools (2.28.1-0ubuntu2) karmic; urgency=low

  * Add debian/patches/85_user_gnome_about_me_for_password.patch to
    use gnome-about-me to change the active users password. gnome-about-me
    doesn't force the change as root, and so allows things (e.g. ecryptfs)
    in the PAM stack to access the old password as it is changed.
    (LP: #307019)
    - Depend on gnome-control-center so that gnome-about-me is available.
    - Also include translations taken from gnome-control-center so that
      the change doesn't mean that the new button is untranslated for
      most users.

 -- James Westby <email address hidden> Wed, 21 Oct 2009 15:34:58 +0100

Changed in gnome-system-tools (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

After asking on the D-Bus list, Thiago Macieira told me that it was safe to send the plain text password over the bus, as long as we're on the same host (which is always the case AFAIK), and that we're using the system bus. So I think I'll make that change in the next cycle, so that we use PAM or passwd (any reason to prefer one over the other?).

This won't solve the present bug actually, but I guess I'll also special-case the current user so that we ask for the old password, and run passwd unprivileged then. But that leaves a breach when you change a user's password as administrator. We could still send the old password to the backends (if provided), which would use su to run passwd as the user. But that may be over-engineered... Not sure what would be the cleanest solution in the long term.

Changed in system-tools-backends (Ubuntu):
status: Confirmed → Triaged
ls colby (ls-colby)
Changed in gnome-control-center (Ubuntu):
status: Fix Released → Invalid
status: Invalid → Fix Released
Revision history for this message
dotnetCarpenter (activ876) wrote :

This is still an issue for me. I added logs ect in bug #527271 to help developers (as I didn't know what was needed and used the ubuntu-bug feature).

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

This is fixed since the 2.9 series.

Changed in system-tools-backends (Ubuntu):
importance: Undecided → High
status: Triaged → Fix Released
assignee: James Westby (james-w) → nobody
Changed in gnome-system-tools (Ubuntu):
assignee: James Westby (james-w) → nobody
Revision history for this message
dotnetCarpenter (activ876) wrote :

@Milan Bouchet-Valat: The 2.9 series? What do you mean? It can't be Ubuntu so I guess you mean Linux, but that has never been a problem because you can use psswd which always works. This bug is about the gnome-control-center (Ubuntu) that has a bug.

Are you sure about your categorization?

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Oh, I thought that was clear from the package I updated the status for. I meant system-tools-backends 2.9. And when I say "Fix Released", this means in the development version 10.04, which explains why you can still experience the bug in Karmic.

Changed in system-tools-backends (Ubuntu):
status: Fix Released → Confirmed
Changed in gnome-system-tools (Ubuntu):
status: Fix Released → New
status: New → Confirmed
Changed in gnome-control-center (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Fabián Rodríguez (magicfab) wrote :

Sorry to reopen this, I've just tested in in two different up-to-date systems using Lucid RC, same issue: changing another user's password via System > Administration > Users and Groups effectively locks out account. Changing it back to the original password from command line (via console) worked for me.

Revision history for this message
Fabián Rodríguez (magicfab) wrote :

When attempting to login to such a locked-out account, one will get the following error dialogs:
Could not update ICEauthority file /home/$USER/.ICEauthority [Close]
There is a problem with the configuration server. (/usr/lib/libgconf2-4/gconf-sanity-check-2 exited with status 256) [Close]
Nautilus could not create the following required folders: /home/$USER/Desktop, /home/$user/.nautilus. Before running Nautilus, please create these folders, or set permissions such that Nautilus can create them [OK]

Once you click on [OK] on the third error message the background graphic will stay but nothing happens. At this point I had to use a console (CTRL ALT F1) to login as the admin user, reset the password and restart GDM (leading to data loss if any other sessions were open).

Revision history for this message
Fabián Rodríguez (magicfab) wrote :
Revision history for this message
Fabián Rodríguez (magicfab) wrote :
Revision history for this message
Kees Cook (kees) wrote :

Please open a new bug report, this is strictly about changing one's own password. Changing another user's password will break ecryptfs since the original password is not known.

Changed in gnome-control-center (Ubuntu):
status: Confirmed → Fix Released
Changed in gnome-system-tools (Ubuntu):
status: Confirmed → Fix Released
Changed in system-tools-backends (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Yes, we have no way to avoid breaking eCryptfs if we don't have the original password. Anyway, if the admin was able to provide it, we could'nt use it because either we run 'passd' as root, and old password is not asked for, or we run it as a standard user, and changing password for someone else is not allowed. Best solution would be that a GUI asks the user for its old password on next login.

For the error messages, please have a look at the permissions of the user's home dir. I don't think the eCryptfs issue could lock out an user *as long as its home dir isn't fully encrypted* (which you don't explain). So permissions may be the real problem here, not eCryptfs. Definitely worth a new report.

Revision history for this message
Open Tech (opentech-opentech) wrote :

We tested an Ubuntu 11.04 today regarding this problem.

The conclusion is, that you have to perform tidious, manual commands in the shell in order to create new users in Ubuntu, if encryption is enabled. It seems, that new users are born with insufficient permissions to live.

In order to create a new encrypted user, named "Ann" in a group "Users", in Ubuntu, you have to add the following commands to your procedure for creating new users.

cd /home
ls -ld ann
sudo chown ann:users ann
sudo chmod 0770 ann
ls -ld ann

Revision history for this message
Milan Bouchet-Valat (nalimilan) wrote :

Open Tech: What?! This bug is fixed for a long time. Please open a new report and include the output of the commands you listed above in the description. And explain how you created this new user.

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

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