Stable library API

[mhogomchungu]

Creating a frontend for fscrypt requires a lot of parsing of its output and parsing is usually very sensitive the presence or absence of space and new line characters.

1. Does fscrypt have a stable CLI output?
2. If no, is it expected to have one at some point in the future?
3. Is there a recommended way for frontends to use fscrypt?

[josephlr]

So I think the goal here would not be to have a stable CLI output for fscrypt, but to improve the fscrypt library enough so that frontends could just call into the library, leaving the CLI tool as a relativly thin wrapper around the library.

We are far from this goal right now, and most of my time and @ebiggers time is spent on #148 and the like. However, this would (ideally) be the next thing to tackle.

[mhogomchungu]

Another thing worth looking into is having a way for fscrypt to report a list of unlocked directories.

Fscrypt compares itself to eCryptfs and this projects adds entries of its unlocked folders to "/proc/self/mountinfo".

Fscrypt also compares itself to dm-crypt and this project adds entries of its unlocked volumes at "/dev/mapper"/

Mount command used to keep its list in "/etc/mtab" file and now the recommended way to get a list of mounted volumes is by parsing "/proc/self/mountinfo"

Fuse project has nothing to do with mounting and it adds its entries in "/proc/self/mountinfo".

I think fscrypt should do the same and it should be possible for frontends to just wake up and somehow get a list of all unlocked directories and "/proc/self/mountinfo" seems to be the obvious place to look for them, if its possible.

[ebiggers]

We already discussed the unlocked directory list when you asked at #157, and I explained that it isn't really possible given how Linux native filesystem encryption works --- though fscrypt can provide a list of unlocked encryption policies. If you have more questions or suggestions about it please re-open that issue; let's keep this one focused on CLI output.

Regarding CLI output, I don't think we can commit to the CLI output being stable yet, as we need the flexibility to continue to make fscrypt better and more usable. As @josephlr suggested, the best solution might be to use the library rather than the command-line tool directly. Also, if you could list exactly which CLI functionality you're actually using that might also be helpful. If it's really only a couple problematic cases (maybe fscrypt status?) it's possible we could add command-line flags to control the output format, and maybe indicate different errors via different exit statuses.

[mhogomchungu]

I have no issues with using a library.

My project is here: http://mhogomchungu.github.io/sirikali and code for fscrypt backend is here: https://github.com/mhogomchungu/sirikali/blob/master/src/engines/fscrypt.cpp

Commands i use right now.

fscrypt status
fscrypt status $FOLDER_PATH
fscrypt status $MOUNT_PATH
fscrypt unlock --quiet $FOLDER_PATH --user=$USER
fscrypt lock $FOLDER_PATH --user=$USER
fscrypt encrypt --source=custom_passphrase --name=$NAME --quiet --user=$USER
fscrypt metadata dump --policy=$MOUNTPOINT:$POLICY

Going forward, i plan to support only V2 policies and git version does this already.

Its trivial to get $MOUNT_POINT when i already know $FOLDER_PATH.
Its trivial to get $NAME when i already know $FOLDER_PATH.
Its trivial to get protectors and policies when i already know $FOLDER_PATH.

The biggest problem i have right now is how $FOLDER_PATH can be remembered between application restarts because it is a run time information and my current policy says SiriKali should not maintain states and should obtain them either from tools themselves, or from the kernel.

My current thinking and git does it is to embed $FOLDER_PATH in the protector's comment. This means fscrypt will manage the information and but it has obvious issues but it workable for my tests.

Another solution is for SiriKali to maintain the information in a config file and this has issues like not knowing encrypted directories created outside of SiriKali.

A crazy idea i had earlier is to somehow use fuse passthrough file system(I currently dont know anything about how to implement a fuse file system). This will allow me to get a list of unlocked volumes by parsing "/proc/self/mountinfo".