encFS - a simple way to encrypt dropbox folders

[netnomad]

hi friends,

dropbox can be very convenient, but do you think it's secure?
a way to use dropbox in a more secure way is to use an encFS-encrypted container.
encFS is lean and clean.
my longterm experience with encFS is very positive, cause it's stable and easy to use.

is there a volunteer who would be so kind to package encFS?

thank you for your help and your commitment.

[caminati]

is there a volunteer who would be so kind to package encFS?

I have packaged encfs.tcz for personal successful use. Yes, it is nice software (apart from boost dependency).
However, each time I have to chown tc /dev/fuse, or encfs won't work.
Basically, the problem is that /dev/fuse has not the right owner or permissions, probably due to a bug with udev rules.
I don't have udev knowledge to track down the issue, nor the time to build such knowledge.

So I refrained from submitting encfs up to now.
Any suggestion?

[curaga]

The default udev rules set fuse to 666 root:root, and mount fusectl. We haven't changed that.

What does encfs want it to be?

[Rich]

Hi curaga

What does encfs want it to be?

I did a little Googling last night on fuse, and I think it's supposed to be  root/fuse 660, and the user is supposed to
be added to group fuse.
I'm running TC4.1, and my machine shows  /dev/fuse  is  root/root 600

[caminati]

I'm running TC4.1, and my machine shows  /dev/fuse  is  root/root 600

I have TC4.6.1, and my /dev/fuse has exactly the same attributes as Rich's.
Some trial and error shows that encfs works, without chowning, by doing chmod o+rw (resulting in a 606).

The encfs error message is:

Code: [Select]

fuse: failed to open /dev/fuse: Permission denied
fuse failed.  Common problems:
 - fuse kernel module not installed (modprobe fuse)
 - invalid options -- see usage message,
which is quoted also here:
https://answers.launchpad.net/encfs/+question/22951
and here:
http://lists.debian.org/debian-user/2011/10/msg00530.html.

Applying the solution

Code: [Select]

sudo addgroup fuse
sudo addgroup tc fuse
didn't solve the problem. But maybe I have to check build parameters for encfs.

[Rich]

Hi caminati
Your first solution works because you made /dev/fuse accessible to all users.
Your second solution was close, you still need to:

Code: [Select]

sudo chown root:fuse /dev/fuse

[AmatCoder]

When fuse.tcz is loaded, you must do this:

Code: [Select]

tc@box:~$ sudo udevadm control --reload-rules
Perhaps this code should be added into /tce.installed/fuse script...

[tinypoodle]

When fuse.tcz is loaded, you must do this:

Code: [Select]

tc@box:~$ sudo udevadm control --reload-rules
Perhaps this code should be added into /tce.installed/fuse script...

Do you refer to specific application making use of fuse, or in general for fuse?

[AmatCoder]

In general. Right now, udev fuse rules (see 99-fuse.rules file which comes with fuse extension) are not applied until rules are reloaded.

[tinypoodle]

When fuse.tcz is loaded, you must do this:

Code: [Select]

tc@box:~$ sudo udevadm control --reload-rules
Perhaps this code should be added into /tce.installed/fuse script...

Or in other case should be worth mentioning in info file at least

[AmatCoder]

hmm, actually it requires:

Code: [Select]

tc@box:~$ sudo udevadm control --reload-rules
tc@box:~$ sudo udevadm trigger --action=change --sysname-match=fuse
because /dev/fuse is created at boot time and /udevadm control --reload-rules/ does not apply any changes to already existing devices...

[caminati]

Hi caminati
Your first solution works because you made /dev/fuse accessible to all users.
Your second solution was close, you still need to:

Code: [Select]

sudo chown root:fuse /dev/fuse

Yes, it was implied that I also chowned: however, that doesn't solve the issue.
By the way, it seems that the problem is absent before i tce-load -i firmware.tcz, probably because its initialization script does

Code: [Select]

udevadm trigger.

hmm, actually it requires:

Code: [Select]

tc@box:~$ sudo udevadm control --reload-rules
tc@box:~$ sudo udevadm trigger --action=change --sysname-match=fuse
because /dev/fuse is created at boot time and /udevadm control --reload-rules/ does not apply any changes to already existing devices...

This works for me.
Is there any reason not to include the above udevadm commands in fuse.tcz's tce.install?
Should we PM Daniel Barnes?
For the moment I have submitted encfs.tcz with those commands suggested in info file.

[Rich]

Hi caminati
Since the  99-fuse.rules file  is supplied with this extension, the tce.install script should probably make sure the
rules are initiated.

[caminati]

Hi caminati
Since the  99-fuse.rules file  is supplied with this extension, the tce.install script should probably make sure the
rules are initiated.

I'm afraid I don't understand the term initiated here.
Is it udev jargon?
Do you mean that you agree tce.install script in fuse.tcz should be added AmatCoder's commands?

[Juanito]

no, since the fuse udev rules are in your extension, the script needs to be in your extension