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

multiple login nodes (multiple lustre client), how should I correctly apply the fscrypt tool to encrypt files under shared storage? #389

Open
voidspiral opened this issue Nov 3, 2023 · 1 comment
Labels

Comments

@voidspiral
Copy link

If I'm in an HPC environment with multiple login nodes, such as login1, login2..., login3..., HPC generally uses LDAP to manage account login information for these nodes. On login1, I log in with the user1 account and execute fscrypt setup, which creates a .fscrypt folder in the / directory. I then run fscrypt setup /mnt/lustre using login as the login key, followed by fscrypt encryption dir and locking the file. However, when I log in to login2 with the user1 account and execute fscrypt unlock, the fscrypt program cannot find the metadata information located in the / directory, and it prompts the following error.

"ttt" is encrypted with fscrypt.

Policy:   2700eb1e6f935208b14ca12a4aff3b25
Options:  padding:32  contents:AES_256_XTS  filenames:AES_256_CTS  policy_version:2
Unlocked: No

Protected with 2 protectors:
PROTECTOR         LINKED  DESCRIPTION
                          [cannot follow filesystem link "UUID=1cddd903-cbe0-4491-bf06-a98504e8b27c\nPATH=/\n": protector metadata for a50d4adfab0ce6a2 not found on filesystem /]
a405cfc9c27eebc7  No      custom protector "Recovery passphrase for ttt"

In this scenario with multiple login nodes, how should I correctly apply the fscrypt tool to encrypt files under shared storage?

@ebiggers
Copy link
Collaborator

ebiggers commented Nov 3, 2023

fscrypt login protectors are always stored in the root directory, for the reasons mentioned at #164 (comment). So they're local to the system.

I think this is the first time that the use case of multiple systems with a shared login and shared encrypted directory has been brought up. Perhaps because the filesystems on which upstream Linux supports native encryption have traditionally all been local filesystems. The first non-local one, CephFS, was added in Linux v6.6 which was just released a few days ago. The Lustre support has been around a bit longer but isn't upstream.

It might be helpful to check with the Lustre developers if they have something in mind for your use case already. But, I think the best advice I can give for now, for this use case, is to just use a custom passphrase protector instead of a login protector.

It would be possible to add support to fscrypt for per-filesystem login protectors, which would support this use case. It's worth considering, but would it add complexity and would come with the disadvantages mentioned at #164 (comment) so it probably shouldn't be the default option. I'd first like to get a good sense that it would be useful to a significant number of users.

I guess another possibility would be just an option in /etc/fscrypt.conf that would override the mountpoint where login protectors are stored. That would handle the special case where all login protectors are stored / should be stored on one mountpoint that is not the root filesystem.

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

No branches or pull requests

2 participants