udisks does not fix or inform user about bad permissions on /media/<username> directory after uid change

[Wren Turkal]

I am using a just updated copy of 14.04. The version of the udisks2 package is 2.1.3-1.

I changed the UID of a user on my system from 1001 to something else. After the change, the ACL permissions on /media/<username> still reflected the old UID. After I deleted the directory and inserted a usb thumbdrive, the directory was recreated with the correct acl permissions.

ACLs after UID change but before removing the directory:
$ getfacl /media/rat
getfacl: Removing leading '/' from absolute path names
# file: media/rat
# owner: root
# group: root
user::rwx
user:1001:r-x
group::---
mask::r-x
other::---

After removing the dir, inserting a thumb drive, and then removing the thumb drive:
$ getfacl /media/rat
getfacl: Removing leading '/' from absolute path names
# file: media/rat
# owner: root
# group: root
user::rwx
user:rat:r-x
group::---
mask::r-x
other::---

Since udisks controls the /media directory, shouldn't it just verify and update the permissions of the directory?

[Phillip Susi (psusi)]

No, it shouldn't. It generally isn't a good idea to change uids in the first place, and certainly not while logged in. If you do, then the change does not take affect until you log out and back in anyhow, and any permissions in the filesystem will not be updated unless you update them.

[Wren Turkal (wt-penguintechs-org)]

Sure, changing a uid is not that common, but it is a supported operation
through the usermod tool, and there are valid reasons to do it.

In this specific case, I didn't change the uid while logged in. I logged
out, logged in with a different user on tty1, "sudo -i" to get a root
shell, then changed the uid of said user, and then chowned the old home to
the new uid.

Also, I even rebooted after doing this and not being able to mount media as
said user. I thought maybe the system (I didn't know about udisks yet)
would fix things on reboot. However, it did not.

Honestly, udisk creates the user's media directory. I found the code that
does it. However, it just silently does nothing in the case where the
directory already exists. Why shouldn't it fix the same directory when it
has the wrong permissions? If security is a concern, I can understand that.
At the very least, it should inform the user of the situation so that they
don't have to troubleshoot such an issue blindly. As it stands now, it's
just bad UX.

wt
On Jun 30, 2014 8:01 AM, "Phillip Susi" <email address hidden> wrote:

> No, it shouldn't. It generally isn't a good idea to change uids in the
> first place, and certainly not while logged in. If you do, then the
> change does not take affect until you log out and back in anyhow, and
> any permissions in the filesystem will not be updated unless you update
> them.
>
>
> ** Changed in: udisks2 (Ubuntu)
> Status: New => Invalid
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1335384
>
> Title:
> udisks does not update permissions on /media/<username> directory
> after uid change
>
> Status in “udisks2” package in Ubuntu:
> Invalid
>
> Bug description:
> I am using a just updated copy of 14.04. The version of the udisks2
> package is 2.1.3-1.
>
> I changed the UID of a user on my system from 1001 to something else.
> After the change, the ACL permissions on /media/<username> still
> reflected the old UID. After I deleted the directory and inserted a
> usb thumbdrive, the directory was recreated with the correct acl
> permissions.
>
> ACLs after UID change but before removing the directory:
> $ getfacl /media/rat
> getfacl: Removing leading '/' from absolute path names
> # file: media/rat
> # owner: root
> # group: root
> user::rwx
> user:1001:r-x
> group::---
> mask::r-x
> other::---
>
> After removing the dir, inserting a thumb drive, and then removing the
> thumb drive:
> $ getfacl /media/rat
> getfacl: Removing leading '/' from absolute path names
> # file: media/rat
> # owner: root
> # group: root
> user::rwx
> user:rat:r-x
> group::---
> mask::r-x
> other::---
>
> Since udisks controls the /media directory, shouldn't it just verify
> and update the permissions of the directory?
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/1335384/+subscriptions
>

[Wren Turkal (wt-penguintechs-org)]

This bug is not invalid. There is a very real UX concern here.

[Wren Turkal (wt-penguintechs-org)]

Here's some links to code.

Here's the upstream code link:
http://cgit.freedesktop.org/udisks/tree/src/udiskslinuxfilesystem.c#n899

Here's the Utopic code:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/utopic/udisks2/utopic/view/head:/src/udiskslinuxfilesystem.c#L891

Here's the trusty code:
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/udisks2/trusty/view/head:/src/udiskslinuxfilesystem.c#L891

FWIW, the ubuntu package has a patch to mount in /media instead of /run/media.

[Phillip Susi (psusi)]

After changing a uid it is up to you to perform an exhaustive search of the filesystem and update file ownership to the new id. Udisks does not override the permissions because some admins may want to set up the permissions themselves to values that differ from the default udisks picks when it creates the directory.

[Wren Turkal (wt-penguintechs-org)]

Okay, if I understand this correctly, you're saying that we shouldn't even tell the user that the directory that udisks would have created has different permissions than what udisks would have created it with?

[Phillip Susi (psusi)]

Right. Also udisks doesn't have the chance to interact with the user since it is a system daemon.

[Martin Pitt (pitti)]

Right, after changing a UID it's your responsibility to walk over the entire file system and change files/dirs accordingly. This definitively does not just affect /media/, but also quite some files in /var (/var/spool/crontabs/, /var/lib/lightdm-data/, possibly /var/mail/, etc.). So if anything, this should be a wishlist bug against usermod to offer scanning the file system and change them; usermod already does that for some known files, but not all (and the manpage even says that you have to do it manually).

That said, there's some room here for udisks to adjust UIDs of existing /media directories on mounting when it sees that their names and UIDs don't match. It's less obvious what to do with changed GIDs as that might be a deliberate configuration.

[Wren Turkal (wt-penguintechs-org)]

AFAICT, the code doesn't do anything with gids. It only creates the user ACL.

Also, I understand there are other files that probably need their perms changed. However, my only point was that udisks is in a position to be more helpful by either informing the user of what is happening or rewriting permissions. And I imagine that one could use dbus to send a message back to the user.

FWIW, I totally agree with you about changing UIDs. It's a PITA. I just think this UX could be more helpful about either fixing or at least informing the user of the problem.

Also, I file these bugs because I want to be part of making Ubuntu better. I just want you all to know that. I find a lot of these bugs when people complain to me about their computers not working for one reason or another.