Bugzilla Bug 75825

common users should also be able to mount captive-partitions accordingly to the
definitions
in the /etc/fstab.

Currently neither option user(s) nor uid=<name> works as it should.

A user is only able to mount a device if
1) device is read/write for user
2) mount point is read/write for user

As further error the own user can't even umount it right after:
umount: /mnt/captive mount disagrees with the fstab

/etc/fstab:
/dev/hda1 /mnt/captive captive-ntfs users,uid=1000 0 0

/etc/mtab:
lufis /mnt/captive fuse rw,nosuid,nodev,user=<me> 0 0

one user can't read another users mount, neither root can. In my case I'd like
to indicate
that all / multiple users have access to the mounted device. (i.e. with users /
uid= )

User support should be improved, but I don't see how to do this best.

Thanks anyway for integrating it into portage and supporting it. I really like
your work! Great

Thomas Bettler

Created an attachment (id=47369) [edit]
lufis-allow-uid-and-gid.patch

patch for lufis to take uid= and gid= parameters, when the program returns
uid=1 or gid=1.
It has no check if the value is valid.

Please test and comment. A valid fstab entry woudl look like:

/dev/hda1 /mnt/captive captive-ntfs defaults,uid=1000,gid=100 0 0

Hm, nope. I tried your patch but it didn't help.

I still have to mount the device as the user.

Why do you check uid/gid=1 ? Didn't you mean 0 (root,wheel)?
But I also tried to check uid/gid against 0 - still negative.

In my eyes it would be more consistent to check if uid/gid options are given/valid and depending on that forward these values.

Maybe there is an other part (of lufis or maybe fuse or lufs or captive) involved in setting uid/gid permissions.

If I can help you somehow let me know, I will provide you all the things you'd like.
But I'm no hacker and therefore I'm no way able to fix this bug myself.

Anyway Tanks A Lot for your support so far.
Your advise was really quick and half way helpful on our way to fix it.

Lot of Greetings and a happy new year.

What permissions do you have currently? For me it was always the bin group and
user, and this patch tries to attach the uid= user when the uid and/or gid is
1(bin).

I also tried the patch now. At my system it is working very good.

Two questions:

1) I hate to pollute bugzilla with n00b questions, but how do I apply the patch?  Do I just stick it in the files folder and add a epatch line to the .ebuild?

2) Looking over the patch (and only the patch mind you, as I have no idea where emerge downloads actual files to in order to look at the source), I see these lines:

+    // Take uid= and gid= vars when the filesystem returns 1
+    if(fattr.f_uid == (uid_t) 1) {
+        lu_opt_getint(&lu_cfg, "MOUNT", "uid", &option_uid, 0);
+        fattr.f_uid = (uid_t) option_uid;
+    }
+
+    if(fattr.f_gid == (gid_t) 1) {
+        lu_opt_getint(&lu_cfg, "MOUNT", "gid", &option_gid, 0);
+        fattr.f_gid = (gid_t) option_gid;
+    }

My pure guess as to how lu_opt_getint() works would be that the last param is a default value.  If so, souldn't the above lines of code be reduced to:

lu_opt_getint(&lu_cfg, "MOUNT", "uid", &fattr.f_uid, 0);
lu_opt_getint(&lu_cfg, "MOUNT", "gid", &fattr.f_gid, 0);

If my shot in the dark guess is right, this would set the default owner/group to 0 (root), which seems to be a much better default for the owner/group id's than whatever random numbers NT makes up.

On second glance, option_uid and option_gid may still be needed as temp values,
but I still suspect we can get rid of the check for 1 as a magic number and
always default to root owning the files.

Thats one of the problems with the patch .. the last param is no default param,
but instead the type of the string->int conversion. I have no default param at
all so it takes some nonsense value from the memory when I dont give uid= and
gid=.

And sorry, your simplification wont work, because the type is not the same, the
type in brackets in the line below is type conversion.

Another problem is, that you cant even read the permissions as user (with or
without this patch). They are correct .. but this helps little, when the user
cant see and use it.

How to apply the patch?
# emerge lufis
[CTRL+Z] after source unpacked.
# cd /var/tmp/portage/lufis-0.2/work/lufis-0.2
# patch -p1 < /path/to/patch
# fg

Still no success, here.
the uid/gid apply, but there is another problem:

if I mount /mnt/captive as root:
and as root ># ls -l /mnt/captive
rw-rw-rw-     1000 100    file1
...
but as user (uid=1000)
>$ ls -l /mnt/captive
ls: /mnt/captive: Permission denied

if I mount /mnt/captive as user everthing works ok and /mnt/captive doen't deny the permission.

Any ideas what might be wrong here?

Created an attachment (id=47868) [edit]
lufis-allow-uid-and-gid.patch

Better patch, it now avoids strange values if one only gives one of uid= or
gid= or nothing.

Created an attachment (id=47869) [edit]
/sbin/mount.captive

New /sbin/mount.captive

allows root to mount with full user r/w access, and also allows the user to
umount (if option users is in fstab)
What it not aallows, is mounting as user (yet to come ..)

My fstab entry now:
/dev/hda3		/mnt/captive	captive-ntfs   
defaults,noauto,rw,uid=stefan,users 0 0

please test it and comment, tell me that it works for you or give some feedback
..

Thank you, Stefan! This seems to work for me as far as it should.

Using sys-fs/captive-1.1.5-r1 and sys-fs/lufis-0.2 with your second patch and your new /sbin/mount.captive, I CAN
* mount my NTFS partition as root (but not as user, as you said)
* properly set uid and/or gid by /etc/fstab entry
* unmount my NTFS partition as root and as ANY user
* read from and write to any directory or file as root
* read from and write to directories/files as a normal user according to set permissions

I can NOT
* chmod directories (an "Operation not permitted" error message is issued)
* chmod files (no error message, but no effect either)

FWIW, this is my /etc/fstab entry:
/dev/hdb1  /mnt/winxp  captive-ntfs  rw,users,uid=lars,gid=users,noatime,noauto 0 0
and this is the corresponding output line of `mount`:
/dev/hdb1 on /mnt/winxp type fuse (rw,nosuid,nodev,allow_other,default_permissions)

Stefan - this worked fine for me!

Thanks for all the hard work, i now have full access to NTFS.

It works good here too! :)
Tnx for your work.

Is the captive version from
http://dev.gentoo.org/~genstef/files/overlay/sys-fs/captive/
ok for you?

This will also solve bug 77239 as there is no longer a dependancy on gnome-vfs-httpcaptive.
I solved it with an static tarball, if it is not yet on the mirrors, you can get it here:
http://dev.gentoo.org/~genstef/files/overlay/captive-install-static-1.1.5.tar.bz2

Emerged your ebuild, which pulled in the following:
dev-libs/glib-2.6.2
sys-fs/fuse-2.2
sys-fs/lufis-0.3
sys-fs/captive-1.1.5-r2

Everything works as it used to, PLUS:
I can mount as a normal user now, after creating a /etc/fuse.conf with a line 'user_allow_other'.

Anything else we should test?

Thank you all for helping on this bug with testing, its now finally in the
tree.