[Bug 1052038] Re: ecryptfs_fnek_sig missing when login at the same time on cron session close
Tyler Hicks
tyhicks at canonical.com
Wed Dec 5 17:46:06 UTC 2012
Expect script referenced in [Test Case]
** Description changed:
when login at the same time on cron session close, ecryptfs directory
will not be decrypted properly.
- IMPACT:
- * folder/file names created by users at the session are unencrypted
- * in desktop session, xdg-user-dirs-gtk-update or other programs creates
- "Desktop", "Download", etc. with unencrypted folder names
- even if encrypted folders with the same name exist.
- On the next login, unencrypted one will be shown with empty content,
- so users feel all data was lost, in spite of actual data is in encrypted one.
+ [IMPACT]
+ * folder/file names created by users at the session are unencrypted
+ * in desktop session, xdg-user-dirs-gtk-update or other programs creates
+ "Desktop", "Download", etc. with unencrypted folder names
+ even if encrypted folders with the same name exist.
+ On the next login, unencrypted one will be shown with empty content,
+ so users feel all data was lost, in spite of actual data is in encrypted one.
Bug #623708 has quite similar symptom.
+ [Test Case]
+ 1. Install ecryptfs-utils and expect
+ $ sudo apt-get install ecryptfs-utils expect
+ 2. Create user 'foo', with encrypted home, and password 'ubuntu'
+ $ sudo adduser --encrypt-home foo
+ 3. Download the lp1052038-test expect script from the bug attachments
+ 4. In terminal 1, run lp1052038-test in a loop that watches for the eCryptfs encrypted
+ filename prefix
+ $ false ; while [[ $? -ne 0 ]]; do \
+ sudo /tmp/lp1052038-test | grep ECRYPTFS_FNEK_ENCRYPTED ; done
+ 5. In terminal 2, run a loop that su's from root to user foo. This is the loop that
+ will trigger the race condition and cause the loop in terminal 1 to end due to
+ encrypted filenames being detected.
+ $ while ((1)); do sudo su - foo -c 'sleep 0.1s' ; done
- How to reproduce:
- 1. setup a home directory encrypted with ecryptfs
- 2. set cron job of a user,
- for example, just sleeping for 1 minutes
- /etc/cron.d/ecryptfs-test
- "*/2 * * * * user1 sleep 1m"
+ The expected result is that the loops in terminal 1 and terminal 2 will run forever.
+ The buggy result is that the loop in terminal 1 will end with
+ ECRYPTFS_FNEK_ENCRYPTED.<remaining encrypted filename> being printed. This typically
+ happens within 15 seconds, from my experience.
- 3. login at the same time on cron session closed
- for example, login near 00 second in odd minute.
- ==========
- Sep 17 23:32:56 ecryptfs-test login[6019]: pam_ecryptfs: Passphrase file wrapped
- Sep 17 23:33:01 ecryptfs-test CRON[6003]: pam_unix(cron:session): session closed for user user1
- Sep 17 23:33:02 ecryptfs-test login[6012]: pam_unix(login:session): session opened for user user1 by user1(uid=0)
- ==========
+ [Regression Potential]
+ The regression potential is that a user cannot properly access his/her encrypted home
+ directory. This would be a serious regression and I've done extensive testing on
+ Oneiric, Precise, and Quantal to be sure that this will not happen. I've also tested
+ the lesser used encrypted ~/Private use case, as well as the use case where filenames
+ are not encrypted but the file contents are encrypted.
+
+ [Other Info]
+
+ Bug reporter's original reproducer instructions:
+ 1. setup a home directory encrypted with ecryptfs
+ 2. set cron job of a user,
+ for example, just sleeping for 1 minutes
+ /etc/cron.d/ecryptfs-test
+ "*/2 * * * * user1 sleep 1m"
+
+ 3. login at the same time on cron session closed
+ for example, login near 00 second in odd minute.
+ ==========
+ Sep 17 23:32:56 ecryptfs-test login[6019]: pam_ecryptfs: Passphrase file wrapped
+ Sep 17 23:33:01 ecryptfs-test CRON[6003]: pam_unix(cron:session): session closed for user user1
+ Sep 17 23:33:02 ecryptfs-test login[6012]: pam_unix(login:session): session opened for user user1 by user1(uid=0)
+ ==========
Expected results:
- home directory mounted properly
+ home directory mounted properly
- * mount -l
- /home/user1/.Private on /home/user1 type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=ab224e5125be6655,ecryptfs_fnek_sig=9cb9226b29f1b007)
+ * mount -l
+ /home/user1/.Private on /home/user1 type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=ab224e5125be6655,ecryptfs_fnek_sig=9cb9226b29f1b007)
- * keyctl show
- Session Keyring
- -3 --alswrv 1000 -1 keyring: _uid_ses.1000
- 311854780 --alswrv 1000 -1 \_ keyring: _uid.1000
- 110408274 --alswrv 1000 0 \_ user: 9cb9226b29f1b007
- 923006627 --alswrv 1000 0 \_ user: ab224e5125be6655
-
+ * keyctl show
+ Session Keyring
+ -3 --alswrv 1000 -1 keyring: _uid_ses.1000
+ 311854780 --alswrv 1000 -1 \_ keyring: _uid.1000
+ 110408274 --alswrv 1000 0 \_ user: 9cb9226b29f1b007
+ 923006627 --alswrv 1000 0 \_ user: ab224e5125be6655
Actual results:
- home directory mounted without folder/file names are decrypted
+ home directory mounted without folder/file names are decrypted
- * mount -l
- /home/user1/.Private on /home/user1 type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=ab224e5125be6655)
+ * mount -l
+ /home/user1/.Private on /home/user1 type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=ab224e5125be6655)
- * keyctl show
- Session Keyring
- -3 --alswrv 1000 -1 keyring: _uid_ses.1000
- 311854780 --alswrv 1000 -1 \_ keyring: _uid.1000
- 71413043 --alswrv 1000 0 \_ user: ab224e5125be6655
+ * keyctl show
+ Session Keyring
+ -3 --alswrv 1000 -1 keyring: _uid_ses.1000
+ 311854780 --alswrv 1000 -1 \_ keyring: _uid.1000
+ 71413043 --alswrv 1000 0 \_ user: ab224e5125be6655
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: ecryptfs-utils 96-0ubuntu3
ProcVersionSignature: Ubuntu 3.2.0-30.48-generic 3.2.27
Uname: Linux 3.2.0-30-generic x86_64
ApportVersion: 2.0.1-0ubuntu13
Architecture: amd64
Date: Tue Sep 18 00:21:00 2012
InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120823.1)
ProcEnviron:
- TERM=screen-bce
- LANG=ja_JP.UTF-8
- SHELL=/bin/bash
+ TERM=screen-bce
+ LANG=ja_JP.UTF-8
+ SHELL=/bin/bash
SourcePackage: ecryptfs-utils
UpgradeStatus: No upgrade log present (probably fresh install)
** Attachment added: "lp1052038-test"
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1052038/+attachment/3452356/+files/lp1052038-test
** Description changed:
when login at the same time on cron session close, ecryptfs directory
will not be decrypted properly.
[IMPACT]
* folder/file names created by users at the session are unencrypted
* in desktop session, xdg-user-dirs-gtk-update or other programs creates
"Desktop", "Download", etc. with unencrypted folder names
even if encrypted folders with the same name exist.
On the next login, unencrypted one will be shown with empty content,
so users feel all data was lost, in spite of actual data is in encrypted one.
+ * Reproduced on Oneiric through Quantal
Bug #623708 has quite similar symptom.
[Test Case]
- 1. Install ecryptfs-utils and expect
- $ sudo apt-get install ecryptfs-utils expect
- 2. Create user 'foo', with encrypted home, and password 'ubuntu'
- $ sudo adduser --encrypt-home foo
- 3. Download the lp1052038-test expect script from the bug attachments
- 4. In terminal 1, run lp1052038-test in a loop that watches for the eCryptfs encrypted
- filename prefix
- $ false ; while [[ $? -ne 0 ]]; do \
- sudo /tmp/lp1052038-test | grep ECRYPTFS_FNEK_ENCRYPTED ; done
- 5. In terminal 2, run a loop that su's from root to user foo. This is the loop that
- will trigger the race condition and cause the loop in terminal 1 to end due to
- encrypted filenames being detected.
- $ while ((1)); do sudo su - foo -c 'sleep 0.1s' ; done
+ 1. Install ecryptfs-utils and expect
+ $ sudo apt-get install ecryptfs-utils expect
+ 2. Create user 'foo', with encrypted home, and password 'ubuntu'
+ $ sudo adduser --encrypt-home foo
+ 3. Download the lp1052038-test expect script from the bug attachments
+ 4. In terminal 1, run lp1052038-test in a loop that watches for the eCryptfs encrypted
+ filename prefix
+ $ false ; while [[ $? -ne 0 ]]; do \
+ sudo lp1052038-test | grep ECRYPTFS_FNEK_ENCRYPTED ; done
+ 5. In terminal 2, run a loop that su's from root to user foo. This is the loop that
+ will trigger the race condition and cause the loop in terminal 1 to end due to
+ encrypted filenames being detected.
+ $ while ((1)); do sudo su - foo -c 'sleep 0.1s' ; done
- The expected result is that the loops in terminal 1 and terminal 2 will run forever.
- The buggy result is that the loop in terminal 1 will end with
- ECRYPTFS_FNEK_ENCRYPTED.<remaining encrypted filename> being printed. This typically
- happens within 15 seconds, from my experience.
+ The expected result is that the loops in terminal 1 and terminal 2 will run forever.
+ The buggy result is that the loop in terminal 1 will end with
+ ECRYPTFS_FNEK_ENCRYPTED.<remaining encrypted filename> being printed. This typically
+ happens within 15 seconds, from my experience.
[Regression Potential]
- The regression potential is that a user cannot properly access his/her encrypted home
- directory. This would be a serious regression and I've done extensive testing on
- Oneiric, Precise, and Quantal to be sure that this will not happen. I've also tested
- the lesser used encrypted ~/Private use case, as well as the use case where filenames
- are not encrypted but the file contents are encrypted.
+ The regression potential is that a user cannot properly access his/her encrypted home
+ directory. This would be a serious regression and I've done extensive testing on
+ Oneiric, Precise, and Quantal to be sure that this will not happen. I've also tested
+ the lesser used encrypted ~/Private use case, as well as the use case where filenames
+ are not encrypted but the file contents are encrypted.
[Other Info]
- Bug reporter's original reproducer instructions:
+ Bug reporter's original reproducer instructions:
1. setup a home directory encrypted with ecryptfs
2. set cron job of a user,
for example, just sleeping for 1 minutes
/etc/cron.d/ecryptfs-test
"*/2 * * * * user1 sleep 1m"
3. login at the same time on cron session closed
for example, login near 00 second in odd minute.
==========
Sep 17 23:32:56 ecryptfs-test login[6019]: pam_ecryptfs: Passphrase file wrapped
Sep 17 23:33:01 ecryptfs-test CRON[6003]: pam_unix(cron:session): session closed for user user1
Sep 17 23:33:02 ecryptfs-test login[6012]: pam_unix(login:session): session opened for user user1 by user1(uid=0)
==========
Expected results:
home directory mounted properly
* mount -l
/home/user1/.Private on /home/user1 type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=ab224e5125be6655,ecryptfs_fnek_sig=9cb9226b29f1b007)
* keyctl show
Session Keyring
-3 --alswrv 1000 -1 keyring: _uid_ses.1000
311854780 --alswrv 1000 -1 \_ keyring: _uid.1000
110408274 --alswrv 1000 0 \_ user: 9cb9226b29f1b007
923006627 --alswrv 1000 0 \_ user: ab224e5125be6655
Actual results:
home directory mounted without folder/file names are decrypted
* mount -l
/home/user1/.Private on /home/user1 type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=ab224e5125be6655)
* keyctl show
Session Keyring
-3 --alswrv 1000 -1 keyring: _uid_ses.1000
311854780 --alswrv 1000 -1 \_ keyring: _uid.1000
71413043 --alswrv 1000 0 \_ user: ab224e5125be6655
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: ecryptfs-utils 96-0ubuntu3
ProcVersionSignature: Ubuntu 3.2.0-30.48-generic 3.2.27
Uname: Linux 3.2.0-30-generic x86_64
ApportVersion: 2.0.1-0ubuntu13
Architecture: amd64
Date: Tue Sep 18 00:21:00 2012
InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120823.1)
ProcEnviron:
TERM=screen-bce
LANG=ja_JP.UTF-8
SHELL=/bin/bash
SourcePackage: ecryptfs-utils
UpgradeStatus: No upgrade log present (probably fresh install)
** Changed in: ecryptfs-utils (Ubuntu Precise)
Status: In Progress => New
** Changed in: ecryptfs-utils (Ubuntu Precise)
Assignee: Chris J Arges (christopherarges) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1052038
Title:
ecryptfs_fnek_sig missing when login at the same time on cron session
close
Status in eCryptfs:
In Progress
Status in “ecryptfs-utils” package in Ubuntu:
Fix Released
Status in “ecryptfs-utils” source package in Precise:
New
Bug description:
when login at the same time on cron session close, ecryptfs directory
will not be decrypted properly.
[IMPACT]
* folder/file names created by users at the session are unencrypted
* in desktop session, xdg-user-dirs-gtk-update or other programs creates
"Desktop", "Download", etc. with unencrypted folder names
even if encrypted folders with the same name exist.
On the next login, unencrypted one will be shown with empty content,
so users feel all data was lost, in spite of actual data is in encrypted one.
* Reproduced on Oneiric through Quantal
Bug #623708 has quite similar symptom.
[Test Case]
1. Install ecryptfs-utils and expect
$ sudo apt-get install ecryptfs-utils expect
2. Create user 'foo', with encrypted home, and password 'ubuntu'
$ sudo adduser --encrypt-home foo
3. Download the lp1052038-test expect script from the bug attachments
4. In terminal 1, run lp1052038-test in a loop that watches for the eCryptfs encrypted
filename prefix
$ false ; while [[ $? -ne 0 ]]; do \
sudo lp1052038-test | grep ECRYPTFS_FNEK_ENCRYPTED ; done
5. In terminal 2, run a loop that su's from root to user foo. This is the loop that
will trigger the race condition and cause the loop in terminal 1 to end due to
encrypted filenames being detected.
$ while ((1)); do sudo su - foo -c 'sleep 0.1s' ; done
The expected result is that the loops in terminal 1 and terminal 2 will run forever.
The buggy result is that the loop in terminal 1 will end with
ECRYPTFS_FNEK_ENCRYPTED.<remaining encrypted filename> being printed. This typically
happens within 15 seconds, from my experience.
[Regression Potential]
The regression potential is that a user cannot properly access his/her encrypted home
directory. This would be a serious regression and I've done extensive testing on
Oneiric, Precise, and Quantal to be sure that this will not happen. I've also tested
the lesser used encrypted ~/Private use case, as well as the use case where filenames
are not encrypted but the file contents are encrypted.
[Other Info]
Bug reporter's original reproducer instructions:
1. setup a home directory encrypted with ecryptfs
2. set cron job of a user,
for example, just sleeping for 1 minutes
/etc/cron.d/ecryptfs-test
"*/2 * * * * user1 sleep 1m"
3. login at the same time on cron session closed
for example, login near 00 second in odd minute.
==========
Sep 17 23:32:56 ecryptfs-test login[6019]: pam_ecryptfs: Passphrase file wrapped
Sep 17 23:33:01 ecryptfs-test CRON[6003]: pam_unix(cron:session): session closed for user user1
Sep 17 23:33:02 ecryptfs-test login[6012]: pam_unix(login:session): session opened for user user1 by user1(uid=0)
==========
Expected results:
home directory mounted properly
* mount -l
/home/user1/.Private on /home/user1 type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=ab224e5125be6655,ecryptfs_fnek_sig=9cb9226b29f1b007)
* keyctl show
Session Keyring
-3 --alswrv 1000 -1 keyring: _uid_ses.1000
311854780 --alswrv 1000 -1 \_ keyring: _uid.1000
110408274 --alswrv 1000 0 \_ user: 9cb9226b29f1b007
923006627 --alswrv 1000 0 \_ user: ab224e5125be6655
Actual results:
home directory mounted without folder/file names are decrypted
* mount -l
/home/user1/.Private on /home/user1 type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=ab224e5125be6655)
* keyctl show
Session Keyring
-3 --alswrv 1000 -1 keyring: _uid_ses.1000
311854780 --alswrv 1000 -1 \_ keyring: _uid.1000
71413043 --alswrv 1000 0 \_ user: ab224e5125be6655
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: ecryptfs-utils 96-0ubuntu3
ProcVersionSignature: Ubuntu 3.2.0-30.48-generic 3.2.27
Uname: Linux 3.2.0-30-generic x86_64
ApportVersion: 2.0.1-0ubuntu13
Architecture: amd64
Date: Tue Sep 18 00:21:00 2012
InstallationMedia: Ubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120823.1)
ProcEnviron:
TERM=screen-bce
LANG=ja_JP.UTF-8
SHELL=/bin/bash
SourcePackage: ecryptfs-utils
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/1052038/+subscriptions
More information about the Ubuntu-sponsors
mailing list