Ubuntu

Can't set (for me) important partition options

Reported by Daniel Scherdel on 2007-05-15
10
Affects Status Importance Assigned to Milestone
HAL
Won't Fix
Medium
gnome-mount
Won't Fix
Medium
gnome-mount (Ubuntu)
Low
Unassigned
hal (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: gnome-mount

Hi,
I have a FAT and a ntfs partition on my system. I would like to hide (or no automounting) the ntfs partition, so I edited fstab, but the partition is still mounted on startup.
And I like to set the uid, gid, noauto and exec for the fat partition, but this isn't working. I found a guide that said to set those options "right click on a device". Uh windows feeling and:
- the mountpoint isn't moveable. It only uses /media
- the options must be separated by spaces and not by commas like in fstab (not very intuitive)
- if I set common options like "user(s)" und "defaults" it says invalid option, but it don't say which options are valid.
- you can set the security relevant option exec and uid but can`t set gid...

The owner of my partitions is 'unknown' and not my user.

From man gnome-mount

"Note that HAL has a notion of what mount options are valid for a given volume. They are listed in the HAL property volume.mount.valid_options on the device object representing the volume to mount.."

Ok there are the possible options, but no word about why other options are not allowed and HOW TO CHANGE THEM. I thought I am the root or am I not?

So I used "hal-set-property" but there is no documentation for it and it says succinct:

"This program attempts to set property for a device. Note that, due to security considerations, it may not be possible to set a property"

No additional words nessacery.
One more outline from man gnome-mount

"In addition to using HAL as the mechanism for mounting file systems, the /etc/fstab file is also consulted as HAL will refuse to mount any file system listed in this file as it would violate system policy. If this is the case, gnome-mount will invoke mount(1) as the calling user rather than invoking the Mount method on the org.freedesktop.Hal.Device.Volume interface on the device object representing the volume / drive. This means that settings (mount point, mount options, file system type) read by gnome-mount are not passed along as these are already specified in the /etc/fstab file and there are no mechanism to override them. When parsing the /etc/fstab file, gnome-mount (and also HAL for that matter) resolves symbolic links and also respects the LABEL= and UUID= notations. For example, if this line is in /etc/fstab

LABEL=MyVolume /mnt/myvolume auto user,defaults 0 0

then gnome-mount mounts the file system with the label MyVolume via mount(1) and /etc/fstab rather than using the HAL mechanisms."

This sounds like a solution but it is not working. Some options aren't interpreted or ignored, "normal" mounted drives can't be unmounted or are missing in places or computer.

Another solution could be to change the policies in /etc/hal/fdi/policy by editing or creating a file (Not that beginner friendly). I have a lot of respect of such hacks. I would prefer if hal could also use the fstab as mentioned in the man.

Thanks for reading. Feel free to post solutions or hints
Greetings Dan

description: updated

Created an attachment (id=13866)
add gid as a valid mount option for vfat

If I try to use gnome-mount gconf options to specify what gid removable volumes should use when mounted, hal tells gnome-mount that the mount option is invalid. The issue here is the policy specified in 20-storage-methods.fdi.

The patch attached fixes the problem.

Looking at the list of options in the Linux kernel's fs/fat/inode.c, there are a few others missing too:

  nocase
  quiet
  showexec
  debug
  posix
  uni_xlate
  nonumtail
  conv
  fat
  blocksize
  cvf_format
  cvf_options
  sys_immutable

I'm not sure how many of those make sense to allow or not.

Christian Reis (kiko) wrote :

I have the same issue here -- if I supply a gid option in the mount options for vfat volumes in gconf, gnome-mount fails to mount and presents a little dialog saying the mount failed (I miss the exact wording). I've tried adding a hal policy file to work around this but then gnome-mount fails silently. It's funny that adding a umask= option works fine!

Christian Reis (kiko) wrote :

The message is:

  Cannot mount volume.
  Invalid mount option when attempting to mount the volume.

Investigating some hackery of hal policy as I type.

Christian Reis (kiko) wrote :

I've posted a patch upstream, and I'll attach it here for review.

Changed in hal:
assignee: nobody → pitti
importance: Undecided → Low
status: New → Triaged
Changed in hal:
status: Unknown → Confirmed
Christian Reis (kiko) wrote :

I was going to mark the gnome-mount task invalid, but it would be nice if the error message that gnome-mount provides provided you with the hint that the problem lies in the hal configuration, as we spent a long time looking at gnome-mount itself.

Changed in gnome-mount:
status: Unknown → New

Sorry for the lag. This patch requires more work to be secure; the caller should only be allowed to specify groups he's member of; a bit like how we handle uid=. So this needs to be handled in the source code in tools/ in hal.

Martin Pitt (pitti) on 2009-01-27
Changed in hal:
assignee: pitti → nobody
Changed in gnome-mount:
importance: Undecided → Low
status: New → Triaged
David Futcher (bobbo) wrote :

The patch has been rejected upstream (at HAL, http://bugs.freedesktop.org/show_bug.cgi?id=14206):

"Sorry for the lag. This patch requires more work to be secure; the caller
should only be allowed to specify groups he's member of; a bit like how we
handle uid=. So this needs to be handled in the source code in tools/ in hal."

I have therefore marked this as 'patch-rejected-upstream'. If another patch is submited, either here or upstream please replace this tag with a more appropriate one (see https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow)

tags: added: patch-forwarded-upstream
tags: added: patch-rejected-upstream
removed: patch-forwarded-upstream
Changed in hal:
importance: Unknown → Medium
Changed in gnome-mount:
importance: Unknown → Medium
Changed in hal:
importance: Medium → Unknown
Changed in hal:
importance: Unknown → Medium
Changed in hal:
status: Confirmed → Won't Fix
Changed in gnome-mount:
status: New → Won't Fix
dino99 (9d9) wrote :
Changed in hal (Ubuntu):
status: Triaged → Invalid
Changed in gnome-mount (Ubuntu):
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.