change of behavior in 0.7.0 about securefs HOT 11 CLOSED

Can you spawn the securefs instance without going into the background?

Alternatively, you can set the log file with --log xxxxx option, and read from xxxxx the logging messages, whether foreground or background. A named pipe may be able to save disk access.

from securefs.

I once thought to separate securefs into a library and a frontend, but the design of fuse really prevents that. You have to run securefs in another process, not in the least to prevent your GUIs from crashing along if it has any bugs.

from securefs.

It will very much appreciated if you could document how external tools like SiriKali should interface with securefs and have tests that make sure the interface does not change.

Rather, you should tell me about what functionality you need, and I will implement those.

from securefs.

Maybe I can provide a --json option, where all interaction are doing with JSON format, just like those Web APIs.

from securefs.

Can you spawn the securefs instance without going into the background?

I think this will require SiriKali to always be running for the duration of the unlocked volume and it will be a fundamental change of its behavior and will make securefs behave differently from all other supported backends. Both are not good options.

Alternatively, you can set the log file with --log xxxxx option, and read from xxxxx the logging messages, whether foreground or background. A named pipe may be able to save disk access.

The problem will still be there because SiriKali will still get confused if it checks for certain strings in the log file and those strings change(like what is being reported here)

I once thought to separate securefs into a library and a frontend, but the design of fuse really prevents that. 

The library could be just a front end to the CLI calling it through fork()/exec()/waitpid(). Biggest benefit for third party tools is that they will be able to enforce minimum version of securefs and i think its easier to formalize a C API than a CLI interface.

Rather, you should tell me about what functionality you need, and I will implement those.

Right now,the functionality i need is for securefs to have a string that says "Invalid password" when a wrong password is used when attempting to unlock a volume.

In the a future,it will be better if different return values are reported to represent different error messages. Right now,"1" is returned for all errors forcing string parsing to figure out what error occurred and its not very front end friendly..

Below output is an example of how SiriKali creates and unlocks securefs volume

/usr/bin/securefs create  "/home/mtz/qqqq"
/usr/bin/securefs mount -b  -o rw -o fsname=securefs@"/home/mtz/qqqq" -o subtype=securefs "/home/mtz/qqqq" "/home/_/qqqq"

When creating a volume,it interpret a return status of zero as success and anything else as "backend failed".

When unlocking a volume,it interprets a return value of zero as success. On non zero return value,it parses the output looking for "Invalid password" and reports a wrong password when it finds it and "backend failed" when it doesnt. This means,the latest version of SiriKali will report "backend failed" with the latest version of securefs when a wrong password is entered.

from securefs.

Basically you want a table of exit codes for different kinds of failures?

from securefs.

What i want is a securefs documentation for front end developers that documents what the tool expects from its front ends and what results it gives under what circumstances.

A table of exit codes will work best for front ends. I think strings that says what error occurred should still be there and maybe documented as being unreliable and subject to change without any notice if you cant guarantee their consistency.

Backward compatibility should also be important as interfacing with CLI tools that have different behaviors in different version is not easy.

What made it necessary to require a log file to observe securefs outputs?

from securefs.

Logging is essential to securefs. In fact, in the future, run securefs in the background without a log file will be a hard error, rather than a warning these days.

Backward compatibility should also be important as interfacing with CLI tools that have different behaviors in different version is not easy.

The messages are meant for humans, not for CLI tools.

from securefs.

Can you explain the rationale for forcing output to a log file?

What was wrong with printing log messages to stdout/stderror and let users redirect them to a log file if they want it there? Or print to stdout/stderror if the log file is not given?

The new behavior can easily be reversed to the old behavior as seen below:

[mtz@ink ~]$ securefs mount -b --log /dev/stdout cipher plain
Password: 
[Error] [0x7f706a253740] [2017-02-10 05:54:45.822273226 UTC]    Invalid password

[mtz@ink ~]$ 

Will you object to somebody doing the equivalent of above? if yes,why?

from securefs.

securefs mount -b --log /dev/stdout cipher plain

When securefs daemonizes, stdin, stdout and stderr will be redirected to /dev/null, and you will lose all error messages.

from securefs.

On second thought, I decide to let the error message appear on the standard error regardless of settings, until securefs actually mounts the directory (at which point the log file will be opened, if any).

from securefs.