Tiny Core Linux
Tiny Core Extensions => TCE Talk => Extension requests => Topic started by: netnomad on October 31, 2012, 01:40:33 PM
-
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.
-
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?
-
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?
-
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
-
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:
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 (https://answers.launchpad.net/encfs/+question/22951)
and here:
http://lists.debian.org/debian-user/2011/10/msg00530.html (http://lists.debian.org/debian-user/2011/10/msg00530.html).
Applying the solution
sudo addgroup fuse
sudo addgroup tc fuse
didn't solve the problem. But maybe I have to check build parameters for encfs.
-
Hi caminati
Your first solution works because you made /dev/fuse accessible to all users.
Your second solution was close, you still need to:
sudo chown root:fuse /dev/fuse
-
When fuse.tcz is loaded, you must do this:
tc@box:~$ sudo udevadm control --reload-rules
Perhaps this code should be added into /tce.installed/fuse script...
-
When fuse.tcz is loaded, you must do this:
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?
-
In general. Right now, udev fuse rules (see 99-fuse.rules file which comes with fuse extension) are not applied until rules are reloaded.
-
When fuse.tcz is loaded, you must do this:
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
-
hmm, actually it requires:
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...
-
Hi caminati
Your first solution works because you made /dev/fuse accessible to all users.
Your second solution was close, you still need to:
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
udevadm trigger.
hmm, actually it requires:
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.
-
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.
-
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?
-
no, since the fuse udev rules are in your extension, the script needs to be in your extension
-
no, since the fuse udev rules are in your extension, the script needs to be in your extension
Sorry, I'm lost (I admit I don't know how udev works, so maybe it's me): my encfs.tcz has no rules, it only contains three encfs binary files: /usr/local/bin/{encfs,encfsctl,encfssh}, and nothing else.
Moreover, fuse.tcz seems to have the same problem with basically any of its dependers: try
tce-load -i firmware.tcz
tce-load -i fusecompress.tcz {sshfs-fuse-2.2.tcz, sshfs-fuse.tcz} CurlFtpFS.tcz
Using any of these programs fails due to denied permission on /dev/fuse.
Note that you have to use valid ssh/ftp connection to see that.
My impression (see also http://forum.tinycorelinux.net/index.php?topic=11777.0 (http://forum.tinycorelinux.net/index.php?topic=11777.0)) is that the problem is with fuse.tcz. Am I wrong?
-
IMO, those commands should be into tce.install script from fuse.tcz (extension made by Daniel Barnes).
Fuse.tcz ships with a 99-fuse.rules file, so fuse.tcz should ensure its correct implementation (and should not do extensions which depended on it).
-
Ah - I thought the rules were in the proposed extension, sorry for the confusion
-
Ah - I thought the rules were in the proposed extension, sorry for the confusion
No prob.
I queried the tce bugs forum board about the issue, hoping danielibarnes is going to give feedback.
-
Hi caminati
That was my fault, I should have said the fuse extension, not your extension.
-
hi caminati,
thank you for your encfs.tcz-package.
everything works fine after these two mentioned fuse-commands...
you could do it much more convenient for all users,
if you put these in a little script in your package under following path:
/usr/local/tce.installed/
so create that encfs-starting-script /usr/local/tce.installed/encfs
#!/bin/sh
sudo udevadm control --reload-rules
sudo udevadm trigger --action=change --sysname-match=fuse
make it executable f.e. with chmod 700 encfs,
repackage and upload it again.
btw i did that already in my individual meta-package encfs_meta.tcz and everything works fine.
thank you for your help
-
Eh, extensions shouldn't work around other extensions. Better fix that one in fuse.tcz.
-
Eh, extensions shouldn't work around other extensions. Better fix that one in fuse.tcz.
hi curaga,
of course, you are right!
sometimes meta-packages can help to load a set of packages and pre-configurations in one set.
hopefully fuse.tcz will be soon fixed, so this should be the first goal.
-
Rather than adding a new group "fuse", I wonder if it wouldn't be better to compile fuse so that it works with "staff" - if possible of course...
-
Hi Juanito
Since the fuse rules file sets the mode to 666, would the group setting even matter?
-
Problem is that udev has a bug...or an undocumented behavior...Example:
KERNEL=="fuse", MODE="0666"Works...mode is setted. (rule from fuse is like this...)
KERNEL=="fuse", ACTION=="add", MODE="0666"Does not work...mode is ignored. (default rule from udev is like this...)
KERNEL=="fuse", ACTION=="change", MODE="0666"Works...mode is setted.
KERNEL=="fuse", ACTION=="add|change", MODE="0666"Works...mode is setted.
-
Problem is that udev has a bug...or an undocumented behavior...Example:
KERNEL=="fuse", MODE="0666"Works...mode is setted. (rule from fuse is like this...)
KERNEL=="fuse", ACTION=="add", MODE="0666"Does not work...mode is ignored. (default rule from udev is like this...)
KERNEL=="fuse", ACTION=="change", MODE="0666"Works...mode is setted.
KERNEL=="fuse", ACTION=="add|change", MODE="0666"Works...mode is setted.
Quick idea, haven't looked into how udev rules work or anything so feel free to tell me I'm wrong, but mightn't that just mean udev won't perform the add action because it thinks that it's already been added?
-
Hi AmatCoder
Doesn't sound like a bug to me. If the item exists, there is nothing to add, and the rule is skipped.
-
But /dev/fuse is created at boot by udev following default rules... The default rule is:
KERNEL=="fuse", ACTION=="add", MODE="0666", OPTIONS+="static_node=fuse", \
RUN+="/bin/mount -t fusectl fusectl /sys/fs/fuse/connections"
And at boot, udev is executed as we can see in /etc/init.d/rcS :
# Start Udev to populate /dev and handle hotplug events
echo -n "${BLUE}Starting udev daemon for hotplug support...${NORMAL}"
/sbin/udevd --daemon 2>&1 >/dev/null
/sbin/udevadm trigger --action=add 2>&1 >/dev/null &
rotdash $!
echo "${GREEN}Done.${NORMAL}"
Note that action triggered is "add", so mode should be setted...
-
Oh, now I can see what's happening....
Some tce.installed scripts (e.g.: alsa.tcz) do:udevadm trigger
If you run this without --action parameter then default action is "change"... So rules with ACTION=="add" are skipped, devices are preserved BUT permission is set to default mode (600):
[...]
udev_node_mknod: preserve file '/dev/fuse', because it has correct dev_t
udev_node_mknod: set permissions /dev/fuse, 020600, uid=0, gid=0
[...]
-
Oh, now I can see what's happening....
Some tce.installed scripts (e.g.: alsa.tcz) do:udevadm trigger
If you run this without --action parameter then default action is "change"... So rules with ACTION=="add" are skipped, devices are preserved BUT permission is set to default mode (600):
[...]
udev_node_mknod: preserve file '/dev/fuse', because it has correct dev_t
udev_node_mknod: set permissions /dev/fuse, 020600, uid=0, gid=0
[...]
Thanks for your analysis.
You seem to be one of the ones having deepest insight here about udev stuff.
What is the appropriate way to deal with the problem?
Maybe amending all the extensions blindly doing udevadm trigger ?
-
Removing the "ACTION" clause from fuse.tcz ought to do.
Note that the change action is the correct one, calling add would re-add all existing devices which could break things.
-
hi friends,
thank you for all your helpful replies.
i solved my last issues with an own meta-package,
but what could we do that it works with the standard-packages in the repository?
i guess that fuse.tcz should be optimized?
or ought there be changes in encfs.tcz, too?
thank you for further hints or recommendations...
-
Netnomad just brought this thread to my attention. I am doing some research on the the issue. Is there a consensus on the change which should be made to the fuse extension?
Thanks,
Daniel
-
Netnomad just brought this thread to my attention. I am doing some research on the the issue. Is there a consensus on the change which should be made to the fuse extension?
Thanks,
Daniel
I didn't grasp the last comment by curaga. However, AmatCoder's solution (see http://forum.tinycorelinux.net/index.php/topic,14326.0.html (http://forum.tinycorelinux.net/index.php/topic,14326.0.html)) is working for me.
Maybe someone wants to test it (unsquashfs fuse.tcz; append the two lines to usr/local/tce.installed/fuse, followed by a newline; mksquashfs into a.tcz; substitute fuse.tcz with a.tcz; do all this as root) further?