Bug 195860 - /bin/mount has a weird notion of "default user" - at least for udf
/bin/mount has a weird notion of "default user" - at least for udf
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-18 17:44 EDT by Michal Jaegermann
Modified: 2008-04-03 17:15 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-03 17:15:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 6124 None None None Never

  None (edit)
Description Michal Jaegermann 2006-06-18 17:44:40 EDT
Description of problem:

'man mount' says, in "Mount options for udf", the following:

 uid=   Set the default user

It is not really clear what that is supposed to mean but one
would expect a behaviour as described for "uid=value and gid=value"
in "Mount options for iso9660" where this is explicit.

Unfortunately (because gnome-mount is stuck of using udf for
some CD) for a value of uid=400 i see only '400 4294967295' in
an ownership of a mount point and all other files and directories
on that CD retain owner and a group of whomever created that CD
on another machine.

In this particular case this has a side-effect of making CD data
inaccesible.

Version-Release number of selected component (if applicable):
util-linux-2.13-0.20.1
util-linux-2.13-0.26 from rawhide behaves the same way

How reproducible:
Always.  It is enough to do a loop mount of a CD image, if udf will
be accepted, to see that uid, and gid, specifications have no real
effect.
Comment 1 Eric Sandeen 2006-09-25 15:30:17 EDT
The options are better explained in the kernel Documentation/filesystems/udf.txt
file:

====
        gid=            Set the default group.
...
        uid=            Set the default user.
...
The uid= and gid= options need a bit more explaining.  They will accept a
decimal numeric value which will be used as the default ID for that mount.
They will also accept the string "ignore" and "forget".  For files on the disk
that are owned by nobody ( -1 ), they will instead look as if they are owned
by the default ID.  The ignore option causes the default ID to override all
IDs on the disk, not just -1.  The forget option causes all IDs to be written
to disk as -1, so when the media is later remounted, they will appear to be
owned by whatever default ID it is mounted with at that time.

For typical desktop use of removable media, you should set the ID to that
of the interactively logged on user, and also specify both the forget and
ignore options.  This way the interactive user will always see the files
on the disk as belonging to him.

===

So it sounds like mounting with "uid=ignore" may solve the issue, and allow you
to read all files.  As far as what Gnome should be using for mount options, I'm
not certain... I think the udf code is behaving as expected, though.
Comment 2 Michal Jaegermann 2006-09-25 16:52:56 EDT
> So it sounds like mounting with "uid=ignore" may solve the issue...

Sigh! There are still no ways to configure options used by gnome-mount
(not mentioning things like making them filesystem specific).
In other words you are really saying "do not use desktop mount tools
to mount CDs as this is broken in many ways".  I am afraid that
you are correct and it looks that things are getting here even
more broken.

OTOH problems still remain.  One is that 'mount' manpage is at least
incomplete if one needs to read Documentation/filesystems/udf.txt
to get explanations what manpage may mean and what uid values are
acceptable.

The other problem is that this special behaviour of uid (and gid)
option for udf makes that really unsuitable even for mount via
autofs.  There likely be other CDs, with other file systems on those,
and using "uid=ignore" with those will cause errors.  If I have
to switch to root to mount such CDs then, of course, I can read
all data anyway.

Clearly "uid=forget" is of no use if this is non-writable medium
written on some system elsewhere.
Comment 3 David Zeuthen 2006-09-26 10:45:15 EDT
IMO the kernel is broken insofar mount options with the same name have different
semantics depending on what file system it is. Also, there is no way to even get
a list of what mount options for a file system that a particular instance of the
kernel supports.. and I guess with terrible things like FUSE this is not even
feasible to ask for.. but... that's a rant for another time! :-)

If I understand correctly, would

 # mount -t udf -ouid=500,uid=ignore /dev/hdc /mnt/tmp

do the trick? Or is it

 # mount -t udf -ouid=500,ignore

I need to know so I can fixup hal / gnome-mount for udf. Thanks
Comment 4 Eric Sandeen 2006-09-26 12:34:42 EDT
Looks like the former:

[root@magnesium ~]# mount -t udf -o uid=400,ignore /dev/loop0 /mnt/test
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       or too many mounted file systems
[root@magnesium ~]# dmesg | tail -n 1
udf: bad mount option "ignore" or missing value

[root@magnesium ~]# mount -t udf -o uid=400,uid=ignore /dev/loop0
/mnt/testUDF-fs [root@magnesium ~]# dmesg | tail -n 1
INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp 2006/09/25
14:19 (1ed4)
Comment 5 Michal Jaegermann 2006-09-26 12:48:31 EDT
> mount -t udf -o uid=400,uid=ignore /dev/loop0

Thanks Eric!  At least there is some hope that this can be worked
around but it is a PITA that this rerequires a "special handling"
and a double PITA that 'man mount' is really silent on that.
Comment 6 Eric Sandeen 2006-09-26 13:16:30 EDT
Hmm just to be clear I meant your former example, not my former example :)

IOW -this- works:  

    mount -t udf -o uid=400,uid=ignore

I think you had it right but I was re-reading the bug and -I- got confused,
so... ;-)
Comment 7 Tobias Oed 2007-02-11 15:29:00 EST
That helps a bit but I still have a problem. If I manually mount a disk (as
root) with

mount -t udf /dev/hdb disk -o \
uid=tobias,uid=ignore,gid=tobias,gid=ignore,umask=00000

My mount point looks like this

drw-rw-rw-  3 tobias tobias   252 Jan 16 12:07 disk

As you can see I get the proper user/group. But the permissions are all messed
up. It's no use to 'tobias' to have read/write permissions if he can't browse
the root dir. 
Is this a defect of how the disk was burned ?
Tobias




Comment 8 Eric Sandeen 2007-07-24 15:41:14 EDT
See also http://bugzilla.kernel.org/show_bug.cgi?id=6124

And Andrew just cued up a patch that will hopefully fix this so that it will not
require uid=<username>,uid=ignore

However, I'm not certain about your problem with the permissions on the root dir...
Comment 9 Bug Zapper 2008-04-03 13:29:15 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 10 Michal Jaegermann 2008-04-03 17:15:15 EDT
I have no way to check that at this moment.  Anybody else?

Note You need to log in before you can comment on or make changes to this bug.