Daemon mode?

[ultimate-deej]

Is it supported? If not, is there a workaround?

[jetwhiz]

Hi @ultimate-deej -- I will look into this. Right now daemon mode is disabled for Windows.

AFAIK this has never been implemented in encfs4win, since Windows doesn't really support a daemon mode (similar functionality would require creating and installing a service).

Is it possible that you can kick off encfs4win in a thread so that it can run in the background?

[Zero3]

The logical solution seems to be to not spawn a console window in the first place, perhaps by providing an alternative executable that does not do this. But the question is how to receive the decryption password from the user in a safe way without a console window.

I'm playing around with making a tray icon / settings GUI for running encfs.exe in the background. I'll see if I can find a way of running the console window in the background.

[jetwhiz]

If it's helpful for you, the original encfs4win had a tray icon which used CreateProcess to spawn encfs in the background.

I'm in the process of adding the tray icon code back to the new encfs4win project, but it will probably take a week or two to get it all integrated back in.

[jetwhiz]

Just FYI @Zero3 -- as of Release 1.10.1-RC4, encfsw has been added back into the project (tray icon).

[Zero3]

@jetwhiz Thanks for the notice! The tray is very limited in functionality, but definitely better than nothing. I'm still playing around with an alternative that I intend to release if I ever get it done.

[ultimate-deej]

I think creating a service is exactly how daemon mode should be implemented in windows

[gh223682]

The lack of a daemon mode (not to be confused with a system service) is probably a non-starter for a lot of users. It's definitely preventing me from deploying EncFS more widely.

At the very least, I believe that encfs.exe should be able to read a password from a configuration file and run in the background without any user interaction. I don't think that specifying the password from the command-line is a good idea over the long-run due to process security issues.

I think that @Zero3 has the best idea, i.e. implement a GUI controller so that the encfs.exe process can run in the background. This is how many Linux-to-Windows projects do it. The two processes can communicate securely using a shared secret.

[gh223682]

I agree with @ultimate-deej EncFS should have the functionality to run as a system service, which would:

1. allow system processes to access encrypted data; and
2. allow the user to access encrypted data before an encfs.exe process can be started, i.e. during the login process.

But I don't think this should be the default configuration.

[jetwhiz]

@ultimate-deej @gh223682 -- I believe I have a solution to this issue.

What do you think about this:

1. create a daemon-mode version of encfs4win (encfsd.exe) to complement encfs.exe (command line)
2. port the "--extpass=program" command line option to Windows, allowing use of an external program for password prompt
3. create a system service for encfs4win (future)

[ultimate-deej]

As a user I want that kind of app to be able to start automatically at system start, regardless of how it is implemented. But of course, a standard way for an OS is preferable.

[gh223682]

@jetwhiz I don't see any reason to separate the two. I think encfs.exe should simply run in the background by default, and people can run it in the foreground for debugging purposes with the "-f" option if they want.

encfsctl.exe as already exists as a command-line interface, I assume encfsw.exe will eventually be the GUI controller, and third-parties can contribute their own controllers as well. The future implementation of a system service would just start encfs.exe with the appropriate configuration.

[gh223682]

@jetwhiz Regarding the latest pre-1.10.1-RC5 patches, encfs.exe doesn't allow me to use the "-S" option to pipe in the password unless I run it in the foreground with "-f".

Also, I am curious as to what the design decisions are to start an encfsd.o process instead of just running encfs.exe in the background.

[jetwhiz]

@gh223682 I switched the pipes so now the parent and child processes share the same stdin stdout pipes, so the issue with -S should now be fixed.

From what I can tell, it is impossible to create a process that is both attached to the console (/SUBSYSTEM:CONSOLE) and not attached (/SUBSYSTEM:WINDOWS). If we build the project as WINDOWS then it will be impossible to run it in the foreground (with the -f option), and vice-versa. We need to maintain functional compatibility with upstream (encfs4win needs to behave the same exact way as encfs).

A good tradeoff would be to detect daemon mode and have encfs fork itself, then kill the parent (which will have the encfs child fork still running in the background).

[gh223682]

A good tradeoff would be to detect daemon mode and have encfs fork itself, then kill the parent (which will have the encfs child fork still running in the background).

@jetwhiz Yes, then the parent process can handle acquiring the password, figure out whether the child process needs to run in the foreground or background, and then fork the child process with the appropriate parameters.

[jetwhiz]

@gh223682 The patch for this functionality is here: patch.txt

I have updated the installer to use this patch: encfs4win-pre-1.10.1-RC5

[gh223682]

@jetwhiz I tested all combinations of default background mode vs. foreground mode and piped vs. interactive password entry.

It seems to be working!

applause

[jetwhiz]

@gh223682 -- Great! I'll make this available with 1.10.1-RC5. I'll close this issue after that, so if you still want a system service then open a new issue for it (so it isn't tangled up in the daemon feature request).