For better syntax highlighting and the ability to copy paste the code snippets, view this post on grimoire.science.
One of the problems of a shared system, is that sometimes multiple applications are used by multiple people. Normally this would be solved by the excellent multi-user support inherent to *nix systems. After all, *nix and derivatives were designed to be used by multiple users at the same time.
However, in some cases, it just makes sense for a single application to stay locked until a password is supplied. In any case, encfs is one of the better encryption methods (as long as usability overshadows security) and it’s a good practice to encrypt application data anyway. The case for encryption varies, but weather it’s to make life harder for hackers, or just to stop cloud storage providers from sniffing around, it’s always a good idea. Even if multiple users will not be sharing an account, encryption prevents the
root users or
admins from getting too frisky with your data.
The popular gnome-keyring and other security authentication methods are not a good ﬁt for this since most of them are unlocked all at once and without being linked to a particular program.
Here we will create a few simple bash scripts to generically and ﬂexibly lock and encrypt applications in a way which allows for multiple users to have their own private encrypted instances of shared apps. The complete scripts are located in my Dotﬁles.
The basic requirements are commonly found across most UNIX systems and its derivatives including MacOS, Ubuntu and other Debian distros, RPM based systems etc.
I personally run Arch Linux but that’s just a biased endorsement.
The requirements are:
This is needed for the shell substitutions in the shell script. Found almost everywhere.
This handles the encryption portion. Though everything covered here will require only the base program itself, new users would probably beneﬁt from having one of the GUI interfaces to
encfs as well. I prefer Gnome Encfs Manager.
3. An ASKPASS program
Our basic structure is simple.
Additionally we would like the following features:
Before getting to the creation of a script, I like to experiment with the native shell. In this case this simply involved checking the following:
Additionally the MAN page for
encfs showed me that support for external authentication managers is granted via the
With those preliminaries out of the way, it is time to start scripting. Portions which require the bash shell specifically will have the shebang included.
Always remember to start the script with it and to only put it once, right at the top of the ﬁle.
Initially we might simply set an unlock string as follows:
Since scripts can quickly get clunky without intending too, we will ﬁrst add a simple variable which is suitable for running the external authentication.
As mentioned previously, zenity is the prettier choice, however, it may not be installed everywhere. So we need a fallback.
Git is more or less available everywhere, and it just so happens to have a pretty neat
askpass tool as well.
However, it would be better to wrap them both up in a way to pick one or the other based on the availability. So, we write a simple test.
Honestly the usage of
which instead of
command -v is a bit controversial. However, here I went with
which simply because it seemed faster. The more portable (POSIX compliant) version of the above would use
command -v. For more details check this stack exchange question.
Gnome Encfs Manager defaults to removing the mount point when the stash is unmounted, however, this causes a terminal input demand which needed to be suppressed, hence the directories are created prior to running Encfs.
The above snippet does not deal with situations where:
These are dealt with in the Improvements section of this document.
Now we are in a position to simply mount our stash and run the program.
At this stage the script is not equipped to deal with situations where:
The script runs the program without testing the result of the mount, which will lead to much frustration and weird errors. These edge cases are handled by the code in Handling Authentication.
Several improvements to the basic script created above are discussed in this section.
This is actually not a really important bit, however, I wanted the app directories to start with capital letters. Also I wanted the encrypted data to be stored in a hidden folder.
In any case, this portion of the script uses a bash speciﬁc expansion. At this
point we can also make the
unlockString a little neater.
Now that we have the name, we simply modify the directories.
To ensure that the script is able to eventually deal with situations where the command is run in succession, a check is required to ﬁgure out if the mount point is currently mounted.
If it is mounted, we will unmount it.
Additionally, for cases where the stash does not yet exist, we will need to create the other directory as well. We shall also kill the application if the stash is to be mounted (for security). This portion was aided by this stack exchange thread.
Finally we shall deal with cases where the script executes and the stashes exist, but the password is incorrect. Additionally, we shall deal with managing the ﬂow of control via the
Quite simply, the
$? variable holds the result of the previous command. Hence it can be used to control the ﬂow. This was inspired by the answers here.
For the latest revisions check my Dotﬁles.
It is also reproduced here as a gist, since Medium can’t handle syntax highlighting.
There ought to be a non-terminal way of creating the stash for the ﬁrst time. Also, it may be interesting to work on the rules and conﬁguration schemes for a variety of applications.
Originally published at grimoire.science.