Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue creating filesystem links with libblkid #50

Closed
ghost opened this issue Aug 30, 2017 · 2 comments · Fixed by #54
Closed

Issue creating filesystem links with libblkid #50

ghost opened this issue Aug 30, 2017 · 2 comments · Fixed by #54
Assignees
Labels

Comments

@ghost
Copy link

ghost commented Aug 30, 2017

fscrypt --version
Version:
0.2.0-12-gfe92c00

fscrypt encrypt --verbose /home/bbb
Reading config from "/etc/fscrypt.conf"
/home/bbb is on ext4 filesystem "/home" (/dev/sda2)
ensuring /home/bbb is an empty and readable directory
ensuring /home/bbb supports encryption and filesystem is using fscrypt
creating policy for "/home/bbb"
listing descriptors in "/home/.fscrypt/protectors"
found 0 descriptor(s)
listing descriptors in "/.fscrypt/protectors"
found 0 descriptor(s)
adding additional ProtectorOptions
Your data can be protected with one of the following sources:
1 - Your login passphrase (pam_passphrase)
2 - A custom passphrase (custom_passphrase)
3 - A raw 256-bit key (raw_key)
Enter the source number for the new protector [2 - custom_passphrase]: 1
using source: pam_passphrase
using name: 
creating login protector on "/" instead of "/home"
listing descriptors in "/.fscrypt/protectors"
found 0 descriptor(s)
KeyFunc(login protector for non-root-user, false)
Enter login passphrase for non-root-user: 
Checking login token for non-root-user
running passphrase hash for protector 1a4115c26b47168e
writing metadata to "/.fscrypt/protectors/1a4115c26b47168e"
policy on /home
        Filsystem: ext4
        Options:   [rw nosuid nodev noexec noatime stripe=32708 data=ordered]
        Device:    /dev/sda2
 protector on /
        Filsystem: ext4
        Options:   [rw noatime errors=remount-ro data=ordered]
        Device:    /dev/sda1
successfully read metadata from "/.fscrypt/protectors/1a4115c26b47168e"
blkid_evaluate_spec("/dev/sda1", <cache>) = "/dev/sda1"
blkid_get_tag_value(<cache>, UUID, /dev/sda1) = 
could not remove metadata at "/.fscrypt/protectors/1a4115c26b47168e.link"
successfully removed metadata at "/.fscrypt/protectors/1a4115c26b47168e"
fscrypt encrypt: filesystem /: no UUID: system error: cannot create filesystem link

/dev/sda1 is "/" with encryption feature disabled
/dev/sda2 is "/home" with encryption feature enabled
/home/bbb is owned by non-root-user

Directory is successfully encrypted by non-root-user using custom_passphrase method.
Directory is successfully encrypted by root while owned by root using pam_passphrase method.

I noticed that when using custom_passphrase fscrypt policy is saved in /home/.fscrypt while using pam_passphrase it tries to save it under /.fscrypt which fails.

@josephlr
Copy link
Member

So this is partially "working as intended" and partially a bug.

The first thing is that the metadata for pam_passphrase protectors is always stored on the root filesystem. This is mainly to prevent the passphrase-based protector from becoming out of sync with the login passphrase. This is intentional, but should be described in depth in the documentation.

The second thing is the filesystem /: no UUID: system error: cannot create filesystem link error. This is because if an encrypted file and its protector are on different filesystems, a link must be created so the correct metadata can be found. This uses the filesystem UUID (similar to how /etc/fstab works). However, the library libblkid has unfortunate caching/privilege issues.

I'm use this issue to address the second thing. I'll open a second issue to address the documentation issue.

@josephlr josephlr changed the title [bug] Cannot encrypt directory using pam_passphrase as non-root user Issue creating filesystem links with libblkid Aug 30, 2017
@josephlr josephlr self-assigned this Aug 30, 2017
@josephlr josephlr added the bug label Aug 30, 2017
@josephlr
Copy link
Member

Also, thank you very much @fancytenseletters for these high quality bug reports!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant