devkit-disks: Allowed ntfs-3g mount options

Hello devkitters,

In https://launchpad.net/bugs/349569 it was noted that devkit-disks
does not allow most of the ntfs-3g mount options. So far, ntfs-3g has
shipped a hal fdi as a workaround (attached) which allows those, but
obviously that doesn't work with dk-disks any more.

Is the intention that ./src/devkit-disks-device.c itself gets those
new options, hardcoded? It already expects ntfs-3g after all:| /* this is assuming that ntfs-3g is used */
| 
| static const char *ntfs_defaults[] =       {"uid=",
|                                             "gid=",
|                                             "dmask=0077",
|                                             NULL};
| static const char *ntfs_allow[] =          {"umask=",
|                                             "dmask=",
|                                             "fmask=",
|                                             NULL};
|If it shouldn't be hardcoded, is there any plan to allow overrides?

Personally I think that ntfs-3g has been pretty much the only use case
here, so adding them to devkit-disks-device.c would be okay.

Thanks for comments,

Martin

Hello again,

Martin Pitt [2009-06-10 13:37 +0200]:
> shipped a hal fdi as a workaround (attached)

*cough*

On Wed, 2009-06-10 at 13:37 +0200, Martin Pitt wrote:
> Hello devkitters,
> 
> In https://launchpad.net/bugs/349569 it was noted that devkit-disks
> does not allow most of the ntfs-3g mount options. So far, ntfs-3g has
> shipped a hal fdi as a workaround (attached) which allows those, but
> obviously that doesn't work with dk-disks any more.
> 
> Is the intention that ./src/devkit-disks-device.c itself gets those
> new options, hardcoded? It already expects ntfs-3g after all:
> 
> | /* this is assuming that ntfs-3g is used */
> | 
> | static const char *ntfs_defaults[] =       {"uid=",
> |                                             "gid=",
> |                                             "dmask=0077",
> |                                             NULL};
> | static const char *ntfs_allow[] =          {"umask=",
> |                                             "dmask=",
> |                                             "fmask=",
> |                                             NULL};
> | 
> 
> If it shouldn't be hardcoded, is there any plan to allow overrides?
> 
> Personally I think that ntfs-3g has been pretty much the only use case
> here, so adding them to devkit-disks-device.c would be okay.Hmm, I suppose we can add some more options here but note that there's
no UI in GNOME anymore to configure mount options [1] like with what we
had with gnome-mount (gnome-mount is deprecated, for the gdu backend of
GVfs use gvfs-mount instead).

So, yeah, it's not really helping anything adding mount options expect
for 'force' (see below). Anyway, I'm not opposed to adding more options
if they are not security holes so please send patches if you want this.

Incidentally, the only problem (I think) we currently have with ntfs-3g
is that the driver sometimes refuses to mount the file system if it was
cleanly unmounted. The user experience is really bad; googling for it,
it looks like this

http://media.photobucket.com/image/ntfs-3g%20...
20mount/r3bol/ntfs.png

We can fix it this way

 a) check for this error (do a strstr() on "$Logfile indicates a clean
    shutdown" for example) when seeing an error when mounting NTFS b) use the GMountOperation to put up a dialog asking if the user wants
    to use the 'force' option

 c) remount with the 'force' option

    David

[1] : this is intentional; you shouldn't have to mess around with mount
options, we should do the right thing out of the box. If you have
special needs (like if you are a hacker) you can always just
use /etc/fstab

Hello David,

David Zeuthen [2009-06-12 10:41 -0400]:> Hmm, I suppose we can add some more options here but note that there's
> no UI in GNOME anymore to configure mount options [1]
> [...]
> [1] : this is intentional; you shouldn't have to mess around with mount
> options, we should do the right thing out of the box. If you have
> special needs (like if you are a hacker) you can always just
> use /etc/fstabI actually thought that this was just a transition issue and that the
mount options just weren't exposed in nautilus yet. If it's
intentional, then this is indeed a non-issue.

Dropping the mount options from the UI entirely stops people from
being able to share their USB hard disk with other users on the
system, though. There might be a few other use cases, but this one
seems to be the most obvious to me. I don't consider /etc/fstab a real
alternative, that feels like a step backwards and isn't possible for
non-admin users anyway.

But let's see how this goes..

Thanks for the heads-up,

Martin

On Mon, Jun 15, 2009 at 8:08 AM, Martin Pitt<martin.pitt@ubuntu.com> wrote:

>
> Dropping the mount options from the UI entirely stops people from
> being able to share their USB hard disk with other users on the
> system, though. There might be a few other use cases, but this one
> seems to be the most obvious to me.Sharing devices seems like something that should be properly designed
as a feature, not exposed in some backwards way via obscure mount
options...

On Mon, 2009-06-15 at 09:09 -0400, Matthias Clasen wrote:
> On Mon, Jun 15, 2009 at 8:08 AM, Martin Pitt<martin.pitt@ubuntu.com> wrote:
> 
> >
> > Dropping the mount options from the UI entirely stops people from
> > being able to share their USB hard disk with other users on the
> > system, though. There might be a few other use cases, but this one
> > seems to be the most obvious to me.
> 
> Sharing devices seems like something that should be properly designed
> as a feature, not exposed in some backwards way via obscure mount
> options...Right. Keep in mind that the Mount() method supports the 'remount'
option so presumably if you wanted to share mounts you could hook into
that and then do the right thing e.g. change dmask for FAT mounts. For
example you could write a Nautilus extension that exposes this either
via a Cluebar (like the CD burner one) or menu options. But I think it's
going to be hard to implement anyway, e.g. you can't really do this for
ext3/ext4 since it involves mocking around with permissions on the root
folder.

As Matthias says, sharing "stuff" [1] between desktop sessions will
probably require a lot of up-front design work. My gut feeling is that
sharing a personal thing like a USB drive is not part of this. It's
probably easier for sessions to exchange objects via some other protocol
e.g. instant messaging or a shared folder. I think both Windows and OS X
have something like shared folders.

One interesting question is what the user experience for fast user
switching should be.... today a USB device mounted in session A is not
accessible if you switch into session B on the same console. That's
probably a bug but you can really also argue it's not...

So right now the way things work is that, in session B, you need to auth
as the admin to unmount the device mounted in session A. Then you can
mount it yourself. I think this is probably good enough as it really is
an oddball case and it's good to err on the side of not disclosing /
leaking information by default.

Suggestions welcome.

    David


[1] : With "stuff" meaning things that people fundamentally wants to
share. This is typically documents or even high-level objects like
contacts or messages, not so much an entire file system that happens to
be on a USB gizmo.

On Mon, Jun 15, 2009 at 11:06 AM, David Zeuthen<david@fubar.dk> wrote:
> On Mon, 2009-06-15 at 09:09 -0400, Matthias Clasen wrote:
>> On Mon, Jun 15, 2009 at 8:08 AM, Martin Pitt<martin.pitt@ubuntu.com> wrote:
>>
>> >
>> > Dropping the mount options from the UI entirely stops people from
>> > being able to share their USB hard disk with other users on the
>> > system, though. There might be a few other use cases, but this one
>> > seems to be the most obvious to me.
>>
>> Sharing devices seems like something that should be properly designed
>> as a feature, not exposed in some backwards way via obscure mount
>> options...
>
> Right. Keep in mind that the Mount() method supports the 'remount'
> option so presumably if you wanted to share mounts you could hook into
> that and then do the right thing e.g. change dmask for FAT mounts. For
> example you could write a Nautilus extension that exposes this either
> via a Cluebar (like the CD burner one) or menu options. But I think it's
> going to be hard to implement anyway, e.g. you can't really do this for
> ext3/ext4 since it involves mocking around with permissions on the root
> folder.What about the codepage/iocharset/utf8 type options? Probably everyone
agrees that everything should be unicode, but that doesn't govern
what's already on someone's USB key today. I know this was a big issue
for some people.

Hi,On Mon, 2009-06-15 at 11:37 -0700, Dan Nicholson wrote:
> What about the codepage/iocharset/utf8 type options? Probably everyone
> agrees that everything should be unicode, but that doesn't govern
> what's already on someone's USB key today. I know this was a big issue
> for some people.Hmm, I remember thinking hard about this some time ago and came to the
conclusion that it's not about what's _on disk_, it's about people using
non-UTF8 locales. And it's not something we need to throw UI real estate
at.

Let's look at file systems one by one

 - FAT
   - short file names: 8-bit, using the OEM codepage
   - long file names: uses 16-bit unicode (UCS-2, not UTF-16 IIRC)

 - NTFS
   - using 16-bit unicode (UTF-16, not UCS-2 I think)

 - ISO9660
   - IIRC plain iso9660 is ASCII
   - Most people use Joliet which means filenames are in UCS-2

 - UDF
   - Specifies nine different encodings that can be used

- HFS+
   - some form of UTF-16

 - Linux/Unix filesystems (e.g. ext2, ext3, btrfs, ZFS, xfs, ...)
   - the encoding is not specified...
   - ...and there's no way to specify mount options to
     translate file names

So the morale here is something like this: If we know that the system is
using an UTF-8 locale (e.g. like most modern distros) then filesystems
mounted by DeviceKit-disks with no options will work out of the box with
the two following caveats

 a. FAT short file names may be wrong (we don't _know_ what the OEM
    code page was)

 b. Linux file systems are as-is; filename encoding is not specified
    so you if you use a filesystem with filenames using ISO-8859-1
    then it will look funny in a UTF-8 system [1].

I would argue that a. doesn't really matter. We can't really do anything
at all about b. - personally I think it's totally busted that
filesystems don't specify filename encoding. I guess that's just
UNIX/Linux for you :-/

Anyway, people still complain. Problems typically only arise only when
people are using non-UTF8 locales.

E.g. suppose I'm running in the da_DK.ISO8859-1 locale. Then I insert a
USB disk and the automounter in my session invokes FilesystemMount() on
DeviceKit-disks. Then the FAT file system is mounted using 'utf8' and I
end up seeing weird characters in my terminal and file manager.

The solution for that is simple. The automounter (e.g. Nautilus if you
are using GNOME) should simply just pass the mount options

 utf8=0 iocharset=8859-1

as arguments to the FilesystemMount() call. It knows how to do this
because it knows what locale it is running in. [2]

In conclusion, I don't think we need to expose any options for this.

     David

[1] : That's why there are things like G_FILENAME_ENCODING and
G_BROKEN_FILENAMES to support GLib and GTK+ apps cf.

http://library.gnome.org/devel/glib/unstable/...

so at least programmers only need to care about the one true encoding:
UTF-8 ;-)

[2] : Of course this isn't implemented. But file a bug and add me
(david at fubar.dk) and I'll help make this happen.

Hello David,

David Zeuthen [2009-06-12 10:41 -0400]:
> http://media.photobucket.com/image/ntfs-3g%20...> We can fix it this way