User Accounts does not delete all files when deleting a user with an encrypted folder

Bug #1009607 reported by Paddy Landau
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
accountsservice (Ubuntu)
New
Undecided
Unassigned

Bug Description

System Settings > User Accounts > delete a user:
If the user has an encrypted home folder, this action does not delete his (encrypted) files.

This is a potential (though highly unlikely) security vulnerability, as recreating the user can reveal the previous files (as described below).

How to duplicate:

1. Create a user with an encrypted folder. The easiest way to do this AFAIK is to install gnome-system tools. Start Users & Groups > Add > (fill in details) & "Encrypt home folder to protect sensitive data". You can see that the user has an encrypted folder:
(a) /home/newuser contains two files, viz. Access-Your-Private-Data.desktop and README.txt.
(b) /home/.ecryptfs/newuser/.ecryptfs contains a few files.
(c) /home/.ecryptfs/newuser/.Private contains a few encrypted files.

3. Log into the new user and create a new file with some information, for example a text file on the Desktop.

4. Log out of the new user.

5. Delete the user and his files.
(a) If you do this from gnome-system-tools, this works correctly; it deletes /home/newuser and /home/.ecryptfs/newuser.
(b) But, if you do it from System Settings > User Accounts > "-" > Delete Files, although it deletes /home/newuser, it does not delete /home/.ecryptfs/newuser.

6. Recreate the new user with the same password as before.

7. Log into the new user; you will still see the previous file that you created.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: gnome-control-center 1:3.4.2-0ubuntu0.2
ProcVersionSignature: Ubuntu 3.2.0-24.39-generic 3.2.16
Uname: Linux 3.2.0-24-generic x86_64
ApportVersion: 2.0.1-0ubuntu8
Architecture: amd64
Date: Wed Jun 6 17:34:00 2012
EcryptfsInUse: Yes
ExecutablePath: /usr/bin/gnome-control-center
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120301)
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANGUAGE=en_GB:en
 LANG=en_GB.UTF-8
SourcePackage: gnome-control-center
UpgradeStatus: No upgrade log present (probably fresh install)
usr_lib_gnome-control-center:
 activity-log-manager-control-center 0.9.4-0ubuntu3
 deja-dup 22.0-0ubuntu2
 gnome-bluetooth 3.2.2-0ubuntu5
 indicator-datetime 0.3.94-0ubuntu2

Revision history for this message
Paddy Landau (paddy-landau) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

the GNOME dialog uses accountsservice which calls "/usr/sbin/userdel -r -- <user>", do you get the same issue if you use that command to delete the user account?

Revision history for this message
Paddy Landau (paddy-landau) wrote :

Sebastien, that is an interesting question!

sudo userdel --remove -- newuser
- This gives the same problem.

However, the manual for userdel says:
"On Debian, administrators should usually use deluser(8) instead."

So I tried:

sudo deluser --remove-home -- newuser
- That command worked correctly.

Therefore, the conclusion seems to be that the accountsservice should call "/usr/sbin/deluser --remove-home -- <user>" instead of userdel.

Revision history for this message
Sebastien Bacher (seb128) wrote :

there a 2 issues there then, one is that userdel is buggy, the other one is that accountsservice should use the other command

affects: gnome-control-center (Ubuntu) → accountsservice (Ubuntu)
Revision history for this message
hexafraction (rarkenin) wrote :

Oops, my browser was misbehaving. Status changed back to New.

Changed in accountsservice (Ubuntu):
status: New → Incomplete
status: Incomplete → Opinion
status: Opinion → New
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.