Say I create an encrypted folder and add a file to it:

# mount -t ecryptfs /srv /srv
# echo word > /srv/file

The content of file is unavailable only after unmounting the filesystem.

How can I configure ecryptfs (or use an alternative encryption system on Linux) to avoid having the content of file unencrypted at any time?

One possibility is is run a script that mounts and umounts the ecryptfs filesystem everytime a file is added but the mount password have to be given which creates security risks.


I am not certain an encrypted filesystem is what you want in this use case.

Why not use an alias (see man alias) to make use of the gpg tool (see man gpg) to decrypt/encrypt the specified file/folder on open/close?

Example of this can be found @ my gist page (working example)

While I know this may not be the most ideal solution it should provide a means to encrypt/decrypt file/folders only when needed vs. mounting a disk and leaving the file/folders decrypted at all times.

| improve this answer | |

General answer (as my expert knowledge is AIX EFS, not linux)

When talking about encrypted files - you must distinguish between 'stored' and 'in memory'. What I expect you are experiencing is that the file contents are 'in memory' in clear text - while (I am sure) they are encrypted 'on disk aka stored' or also called - 'at rest'.

Test for you to perform:
* as non-root userA add a file to your encrypted filesystem, mode 644
* as non-root userB - you are not expected to know the encryption key, so ideally you cannot see the 'clear text', better is no access.
* as root, ideally, no access (without decryption key), worst case, can see the encrypted data.

On AIX, so I shall assume that Linux is the same: you will need to have some credentials that allow you to access (the secret key used to encrypt/decrypt) the 'at rest' data and/or access cached representation of same 'in cached memory' data - above and beyond the traditional *NIX DAC access mechanisms.

However, my assumption may be wrong. If Linux is doing encryption per partition rather than per file - having access to the encrypted partition could imply that the only remaining protection is by the classic DAC and/or ACL mechanisms (e.g., extras coming via SELinux and/or AppArmor)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.