maindavfs2 - Support: sr #108528, DAV file system mounted by user...

 
 

sr #108528: DAV file system mounted by user cannot be unmounted by user

Submitter:  Dale Worley <worley>
Submitted:  Tue 11 Mar 2014 04:38:36 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  _71007
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 24 Apr 2014 06:21:18 PM UTC, comment #7: 

Yes. Version 1.5.0, released last Monday.

Werner

- <_71007>
Wed 23 Apr 2014 09:23:22 PM UTC, comment #6: 

Is there a particular version number which will contain this fix?  (Since I can work around the issue, I won't be installing an update from CVS, I will wait until the Fedora distribution provides a new RPM.)

Dale Worley <worley>
Thu 10 Apr 2014 06:32:08 PM UTC, comment #5: 

Simple answer: there is no corresponce. Take the branch name just as an arbitrary character array.

Long answer: after releasing 1.4.6 I started some bigger changes that are still not ready for release. Meanwhile bug fixes and easy to do patches for feature requests piled up and I could not release. So I started a branch for this, starting with the code of the 1.4.6 release. This branch has seen release 1.4.7 and will probably see 1.5.0 soon. But the branch will still be named 1.4.6.

Yes it is confusing and I should have choosen a better name for the branch. But this will all be obsolete when I release 2.0.0 from branch MAIN, at some time in thefuture or some time later.

Werner

- <_71007>
Wed 09 Apr 2014 08:29:01 PM UTC, comment #4: 

I see that in Fedora 19, the current davfs2 RPM has version "davfs2-1.4.7-3.fc19.x86_64", which appears to be version 1.4.7, while you have just created "rel-1-4-6".  Can you tell me the correspondence between the version numbers the distributors use and the branch names?

Dale Worley <worley>
Sat 05 Apr 2014 06:32:57 PM UTC, comment #3: 

The problem is now fixed in the CVS sources branch MAIN and branch rel-1-4-6.

I hope I will be able to do a new release soon.

Werner

- <_71007>
Wed 12 Mar 2014 04:56:24 PM UTC, comment #2: 

Thanks for tracking this down.

Fortunately, in my situation, specifying "users" in /etc/fstab will work well enough.

You note, "If you mount your USB device the output of /proc/mounts and 'mount' will be different. mount shows the additional information from utab."  And indeed, the extra information in /var/run/mount/utab is "user=worley", and that is not present for the dafvs.

I find the creation of /var/run/mount/utab to be amusing.  Originally, all the information was in the file /etc/mtab.  Then there was the idea of moving the information into the kernel, so it was obtainable by /proc/mounts.  Then people discovered that not enough information was being stored, so they created a file to hold it, /var/run/mount/utab.  Nothing has changed in principle, but it's incompatible with the past.

You write, "the header file of libmount is just a list of a zillion structs and functions without any explanation at all".  What ever happened to the rule that one must comment one's code thoroughly?  I can't recall the number of functions I've seen in major packages that have no function summary at all, much less comments on the detailed logic within.

Dale Worley <worley>
Wed 12 Mar 2014 10:40:45 AM UTC, comment #1: 

After some search I found that mount stores additional options (that are not in /proc/mounts) in /var/run/mount/utab. If you mount your USB device the output of /proc/mounts and 'mount' will be different. mount shows the additional information from utab.

There have been a lot of changes to util-linux including mount and libmount. But there is almost no documentation (so what 'man mount' says about the option user is not really true):


To solve the problem I probably had to use libmount in davfs2. But given the amount of spare time and the state of documentation I don't see a chance to do this any time soon. The only advice I can give at the moment is to use a real /etc/mtab instead of a symbolic link.

Werner

- <_71007>
Tue 11 Mar 2014 04:38:36 PM UTC, original submission:  

Software:

Fedora 19
util-linux-2.23.2-5.fc19.x86_64
davfs2-1.4.7-3.fc19.x86_64


Symptoms:

I have a davfs specified in /etc/fstab so:

https://dav.box.com/dav         /home/worley/box.com davfs rw,user,noauto,uid=worley,gid=worley  0 0

The user 'worley' can mount this filesystem with "mount /home/worley/box.com", as one would expect.

But the user 'worley' can't umount this filesystem.  "umount /home/worley/box.com" reports:

umount: /common/home/worley/box.com: umount failed: Operation not permitted

It appears that this error is produced by /usr/sbin/umount itself (not umount.davfs) because renaming /usr/sbin/umount.davfs to something else (thus making it impossible to execute) does not change the observed behavior.

Changing the option in fstab from "user" to "users" allows worley to umount the filesystem.

Looking at the code in evaluate_permissions() in context_umount.c in util-linux suggests that when fstab contains "user", umount looks for a "user=<username>" option in the corresponding entry in /etc/mtab.  On this system, /etc/mtab is a link to /proc/self/mounts.

The three interesting lines in /proc/self/mounts are:

gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
https://dav.box.com/dav /common/home/worley/box.com fuse rw,nosuid,nodev,noexec,relatime,user_id=1000,group_id=1000,allow_other,max_read=31744 0 0

I notice that the line for the davfs does not contain a user= option.  (It does contain user_id=, but I believe that is part of the FUSE system, and is not relevant here.)

By comparison, when I user-mount a USB device, the line in /proc/self/mounts is:

/dev/sdc /mnt/sdc vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0002,dmask=0002,allow_utime=0020,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 0

For /mnt/sdc, the fstab line is:

/dev/sdc                        /mnt/sdc       auto    noauto,user,uid=worley,nodev,nosuid,exec  0 0

And this filesystem is unmountable by 'worley'.

Although it is not clear to my why this works, since the /proc/self/mounts line doesn't contain the user= option either, although it does contain a uid= option.

Dale Worley <worley>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by _71007 (Posted a comment)
  • -email is unavailable- added by worley (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-04-22 _71007 Open/ClosedOpen Closed
    2014-04-05 _71007 StatusPostponed Done
    2014-03-12 _71007 StatusNone Postponed
        Assigned toNone _71007

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code