Existing mounted vfat partition is not writeable for non-root users

[Santiago Erquicia]

I had a vfat partition that I made the installer mount as /windows

When I tried to browse it with nautilus, every folder appeard as a file with a
green foot icon making it unbrowseable.

Besides that, it didn't appear under computer -> disks. To fix this problem I
changed my fstab file from a post I founded through google (which I don't know
if it is correct).

Original fstab:
/dev/hda5 /windows vfat defaults 0 2

New fstab:
/dev/hda5 /windows vfat defaults,user,auto,showexec,umask=0 0 2

[Matt Zimmerman (mdz)]

What would reasonable defaults be for this? It seems excessive for vfat
partitions to be world-writable. Can we use an existing group, of which the
initial user will be a member, and make it read/write by that group?

[Shawn Walker (adonijah)]

I personally did uid=1000,gid=1000 in my fstab instead of user. That way it's
only readable / writeable by my user and user group.

[Santiago Erquicia (santiago-erquicia-gmail)]

I guess that having a vfat partition makes the computer actually a home desktop
and not an enterprise desktop or server, so it should be writable by anyone. If
you are so paranoid (in the good sense) of security, you wouldn't have a desktop
with a vfat partition that doesn't handle the user and group permissions as unix
filesystems.

I don't know if that makes sense but I haven't seen any system with that type of
configuration if it is not a home desktop/laptop.

[Matt Zimmerman (mdz)]

Security and safety are important on desktop systems as well as on servers. In
this case, I don't think any usability is sacrificed if writability is
restricted to privileged users (as it currently is with access to the audio
device, hotplugged devices, etc.)

[Martin Pitt (pitti)]

I would not like to create yet another "vfat" group to put users into. But
conforming to the Warty security policy, only "local" users should be able to
access the vfat partitions. It really does not make sense to restrict access to
a subset of the users.

The standard group that is closest to this interpretation is IMHO "cdrom". So
can we have the files/dirs on vfat/NTFS partitions belong to root:cdrom with
664/775?

[Matt Zimmerman (mdz)]

cdrom, though misleading in name, is closest in terms of the security model, I
agree.

Colin, what do you think?

[Kristof Vansant (de-lupus)]

can't fstab-sync be used to update the fstab for this ?

[Matt Zimmerman (mdz)]

The fstab issue is already dealt with; the question is what ownership and
permissions should be used for the mounted filesystem

[Matt Zimmerman (mdz)]

We must either create a new group, or abuse an existing group. Which is the
lesser evil?

[Martin Pitt (pitti)]

(In reply to comment #9)
> We must either create a new group, or abuse an existing group. Which is the
> lesser evil?

Personally I would not like yet another group. We should take either cdrom or
plugdev. The former is closer to the idea of a "vfat" group, the latter is
compatible to the version where the VFAT partition is on an USB drive (where it
would be pmounted with umask 007).

Since this change must be made in the installer, I reassign this bug to Colin.

[Jon Masters (jcm)]

(In reply to comment #10)
> (In reply to comment #9)
> > We must either create a new group, or abuse an existing group. Which is the
> > lesser evil?
>
> Personally I would not like yet another group.

But you'll need one.

> We should take either cdrom or plugdev.

That's incredibly nondescript and terse, and will only serve to confuse new
users who are reading their fstab. Whereas adding another group wouldn't
actually hurt anything.

In my humble opinion, Ubuntu is about ease of use as much as anything else -
"cdrom" or "plugdev" is not intuitive.

Jon.

[Matt Zimmerman (mdz)]

This group is something which is completely transparent to the uninitiated user,
and while not entirely elegant, at least unsurprising to a UNIX user

[Alexander Kirillov (shurik179)]

IIRC, Fedora uses option "owner" --- that is, ownership of mounted windows
partition is assigned to the first person who logs in locally from console.
Usually it makes sense. Do not know whether debian has anything similar.

[Jay Camp (jayc)]

What we have done is similar to comment #13. For our organization, we're going
to deploy with the options "defaults,noauto,user". While this may not be the
optimal solution (especially for multiseat), I'd say it covers 95% of the use
case where it's a single user system sharing data with Windows and all they do
is what to access their data.

The user option also means that if they add another user to the system, we don't
have to worry about a non-standard group being added, etc.

[Patrice Vetsel (vetsel-patrice)]

Breezy mount vfat partition automatically. It's a great point.
Many users having this type of partition, have choosen vfat for the ability to
have access on it (instead of ntfs).
So they will not understand why they can't have write access on this partition.
If nothing is done, we (community support) will face to a big wave of questions
for this problem.
So in a user oriented distribution, it's a bug.
I think that the best solution is to create a vfat/fat32 group, and add the
first user in.
Others users like your little sister, or children, can read vfat partition too
but can't delete/write on it while first user allow this.

[Martin Pitt (pitti)]

*** Bug 23062 has been marked as a duplicate of this bug. ***

[Martin Pitt (pitti)]

vfat partitions are now readable by anybody, but not writeable. Adapting Summary.

[Suzan (suzan72)]

(In reply to comment #15)

> So in a user oriented distribution, it's a bug.
> I think that the best solution is to create a vfat/fat32 group, and add the
> first user in.

I agree completely! For the most "normal" users this is a bug. To create a
vfat-group is a very good suggestion in my opinion. And of cause, the first user
must be a member of this group! ;-)

[jasonclifford (jason-ukfsn)]

(In reply to comment #4)
> Security and safety are important on desktop systems as well as on servers. In
> this case, I don't think any usability is sacrificed if writability is
> restricted to privileged users (as it currently is with access to the audio
> device, hotplugged devices, etc.)

I disagree - for users who are not familiar with the unix/linux permissions model usability is
definitely lost when a file system they reasonably expect to be writable is not.

Even worse they have to know how to edit /etc/fstab in order to set the permissions so that they
can write to the filesystem.

While security is important if Ubuntu is to be usable for the vast majority of users they will
need easy access to their existing filesystem and to be able to write to it without any action
beyond simply installing the OS.

Certainly an additional group would fix this however that raises rather a lot of complication
and if every user is automatically a member of that group the benefit over simply setting the
umask to 000 is negligable and in practice there really isn't any.

In contrast setting the umask ensures that no matter who is logged in the vfat filesystem simply
works as per reasonable expectation.

This is important given that PCs are now commodity items and an ever increasing number of
families have one which is shared with each member having a login of their own.

[Martin Pitt (pitti)]

My current gut feeling is that we should just make vfat partitions umask=007 and
put them into group plugdev. This would be reasonably compatible with our
handling of removable devices and would safe us from adding yet another group.

Of course no solution would fix upgrades from earlier releases since we cannot
change /etc/fstab, but this should be eventually fixed for dapper.

Opinions?

[Dennis Kaarsemaker (dennis)]

I agree that plugdev is the nicest of the existing groups, cdrom will just be
too confusing imho.

[Patrice Vetsel (vetsel-patrice)]

No news for this bug ?!
:-/

[Colin Watson (cjwatson)]

Hooray, one of the oldest installer bugs finally fixed. Thanks for your suggestions, everyone.

partman-basicfilesystems (46ubuntu2) dapper; urgency=low

  * Mount FAT and NTFS filesystems at boot (fstab pass 1).
  * Mount NTFS with nls=utf8, which is always correct for Ubuntu systems and
    avoids files going missing due to their names containing unconvertable
    characters (suggestion from Malone bug #25071).
  * Mount FAT and NTFS with umask=007,gid=46 (static group plugdev), so that
    users can easily be given privileges to read/write mounted Windows
    filesystems, and so that the first user can do so automatically (closes:
    Malone #8048, #25071).

 -- Colin Watson <email address hidden> Sat, 1 Apr 2006 09:59:59 +0100

[Patrice Vetsel (vetsel-patrice)]

Yes ! :)
Many thanks Colin Watson :p