[SOLVED] Slackware 14.2 RC1 asks for root password, but didn't before 25th March, 2016

gargamel · 03-31-2016, 07:16 PM

EDIT: Marked as unresolved, again, as it turns out that I am not the only one with that problem.

gargamel

i everyone,

I have a weird phenomenon here, and wonder, if it's only my system or if anyone else has similar problems.

Root Password is requested for mounting encrypted internal Harddisk
I have two internal harddisks in my computer, on for the operating system, the other one for photos, music and such. Both harddisks are LUKS encrypted. The first harddisk is decrypted at boot after entering the LUKS passphrase. The second harddisk is decrypted using a key file and /etc/crypttab, when I click on the harddisk icon in Dolphin. This used to work for me as a normal user, and the harddisk was just mounted. A few days ago, however, this changed. When I click on the harddisk icon in Dolphin now, a dialog pops up requesting the root password (yes, the root password, not the LUKS key or passphrase!).

Burning DVDs fails with strange Error Message
Also, I cannot burn DVDs anymore. "Unknown error message" in k3b and "cdrecord: Can you confirm that there is enough space on the media?" or so.

Root Cause?
Now, as long as I use Linux as my main system I haven't become (or even tried to become) an expert or geek. I am still a humble user. One thing I learned about Unix/Linux is, however, that 9 out of 10 issues have to do with wrong file permissions or user privileges. Therefore I think, the changed behaviour might have to do with the recent polkit updates (25th and 26th March, 2016).

Does anyone else have similar issues, or is it just me?

Thanks everyone,

gargamel

specialized · 04-02-2016, 09:51 AM

The same happens in my system, but i guess its a matter of /etc issue and polkitd user and group id, come with the last update, still tryng to figure it out

xflow7 · 04-02-2016, 06:13 PM

Curiously, I was having some strange behavior requiring root to mount an external drive that shouldn't have needed it after the 21-March updates, but they got fixed by the 26-March updates (which included the polkit UID/GID additions).

gargamel · 04-03-2016, 07:27 AM

@specialized. I think the same. So I'll mark the thread as unresolved, again, as I am not the only one experiencing these issues.

@xflow7. I am pretty sure that before 25th March, 2016, the issues weren't present in my system. But the problem with mounting external drives is one of the symptoms of the problem that I tried to describe in my original post. So, maybe the root cause came with one of the previous updated, and the updates of 25th/26th March, 2016, only disclosed them?

At the moment I still have no clue, what exactly is going on.

gargamel

gargamel · 04-03-2016, 07:31 AM

BTW, I am planning for a fresh install, once 14.2 is out. Maybe the issue has to do with some old files interfering with new ones. I don't know. A new install will wipe old, obsolete and potentially interfering stuff.

gargamel

TLE · 04-16-2016, 01:45 PM

Same for me too.

Anyone?

Didier Spaier · 04-16-2016, 02:50 PM

Me too. That's in a VM that I use to build packages and where I rebuilt shadow to include translations of the (internationalized) "adduser" script, so at first I suspected that the issue came from that, but probably not as I am not alone.

The error message is localized:

Code:

mount: seul le superutilisateur peut utiliser mount

In /etc/fstab I have:

Code:

/dev/sdb1   /mnt   auto    noauto,user   0  0

/dev/sdb1 is an EFI partition equipped with a vfat file system of an USB stick with a GPT and a protective MBR and "lsblk -o model,name,fstype" reports an ISO9660 file system in /dev/sdb (device of which /dev/sdb1 is a partition).

However, I have no issue to mount /dev/sdb1 as root in Slackware current in a VirtualBox VM and as a regular user in Slackware 14.1 on bare metal.

gargamel · 04-16-2016, 07:22 PM

The issue persists in 14.2 RC 2.

And yes: For me it is an issue, though a minor one. In fact there might be a reason for the changed behaviour, and if it's security, than so be it. I'd just like to know that the change was intended for some reason, and is not just an unwanted side effect of another change in special setups.

gargamel

BratPit · 04-18-2016, 07:24 AM

For my luks partition works this but maybe root password for mount is not that bad option:

Quote:

/etc/polkit-1/rules.d/10-udisks2.rules

Quote:

polkit.addRule(function(action, subject) {
if (( action.id == "org.freedesktop.udisks2.filesystem-mount" ||
action.id == "org.freedesktop.udisks2.filesystem-mount-system") &&
subject.isInGroup("plugdev") ) {
return "yes";
}

});

but I looked on default 20-plugdev-group-mount-override.rules in /etc/polkit

and replace line:

Quote:

if (action.id == "org.freedesktop.udisks2.filesystem-mount" &&

to

Quote:

if (( action.id == "org.freedesktop.udisks2.filesystem-mount" ||
action.id == "org.freedesktop.udisks2.filesystem-mount-system") &&

the first works only with udisk not udisk2.
Wait Pat fix this issue.

gargamel · 04-18-2016, 02:20 PM

Quote:

Originally Posted by BratPit

For my luks partition works this but maybe root password for mount is not that bad option:

[...]

Wait Pat fix this issue.

Thanks! I'll try your solution on the weekend, when I have a little time.

Yes, I agree: Requesting the root password to mount a disk is not always and not necessarily a bad idea. However, I think it depends on the usage scenario, the disk content and data ownership. E.g., in my setup the root password might in fact make sense, as I am mounting an internal harddisk.

For external hard drives I doubt that the current behaviour is all that useful. I liked the old behaviour when a normal user could connect an external USB harddisk and mount it after providing the LUKS passphrase or the LUKS key. It shouldn't require a system administrator to allow people to backup their data on external drives, as long as security is ensured. Requesting the root password for this in addition to the LUKS passphrase or key does not add to the security, here; I'd even think the opposite is true, because the user can more easily get into possession of the root password this way, by watching the admin entering it, for example.

So no added security, but a loss of comfort, at least for some users and some usage scenarios compared to the previous behaviour.

gargamel

rworkman · 04-20-2016, 02:23 PM

Quote:

Originally Posted by gargamel

Root Password is requested for mounting encrypted internal Harddisk
I have two internal harddisks in my computer, on for the operating system, the other one for photos, music and such. Both harddisks are LUKS encrypted. The first harddisk is decrypted at boot after entering the LUKS passphrase. The second harddisk is decrypted using a key file and /etc/crypttab, when I click on the harddisk icon in Dolphin. This used to work for me as a normal user, and the harddisk was just mounted. A few days ago, however, this changed. When I click on the harddisk icon in Dolphin now, a dialog pops up requesting the root password (yes, the root password, not the LUKS key or passphrase!).

I'm pretty sure this is by design - removable media should still mount/unmount fine, but internal drives require authorization if they're not listed in fstab (and maybe even if they are, depending on fstab settings).

Quote:

Burning DVDs fails with strange Error Message
Also, I cannot burn DVDs anymore. "Unknown error message" in k3b and "cdrecord: Can you confirm that there is enough space on the media?" or so.

I don't know about this one. Does it help to do something similar to the instructions in CHANGES_AND_HINTS.TXT?

Code:

If you have permission errors when attempting to burn a cdrom or dvd image,
  such as the following:
    /usr/bin/cdrecord: Operation not permitted. Cannot send SCSI cmd via ioctl
  then cdrecord almost certainly needs root privileges to work correctly.
  One potential solution is to make the cdrecord and cdrdao binaries suid root,
  but this has possible security implications.  The safest way to do that is
  to make those binaries suid root, owned by a specific group, and executable
  by only root and members of that group.  For most people, the example below
  will be sufficient (but adjust as desired depending on your specific needs):
    chown root:cdrom /usr/bin/cdrecord /usr/bin/cdrdao
    chmod 4750 /usr/bin/cdrecord /usr/bin/cdrdao
  If you don't want all members of the 'cdrom' group to be able to execute the
  two suid binaries, then create a special group (such as 'burning' which is
  recommended by k3b), use it instead of 'cdrom' in the line above, and add
  to it only the users you wish to have access to cdrecord and cdrdao.

Didier Spaier · 04-20-2016, 02:43 PM

Quote:

Originally Posted by rworkman

removable media should still mount/unmount fine

They don't as regular user here, even if listed in /etc/fstab on current. They do on 14.1 (USB stick in this case in this case, with some specificity, see post #7)

volkerdi · 04-20-2016, 02:53 PM

Quote:

Originally Posted by Didier Spaier

They don't as regular user here, even if listed in /etc/fstab on current. They do on 14.1 (USB stick in this case in this case, with some specificity, see post #7)

Removable media is mounting/unmounting in Xfce file manager for me here, as a regular user. No password prompt. The partitions are not listed in fstab, either. Tested with both a USB flash memory stick and a hard drive in a USB attached external bay.

Didier Spaier · 04-20-2016, 03:04 PM

Quote:

Originally Posted by volkerdi

Removable media is mounting/unmounting in Xfce file manager for me here, as a regular user. No password prompt. The partitions are not listed in fstab, either. Tested with both a USB flash memory stick and a hard drive in a USB attached external bay.

I just type the mount command in a terminal in Fluxbox.

PS in an xterm if that matters.

rworkman · 04-20-2016, 10:09 PM

Quote:

Originally Posted by Didier Spaier

I just type the mount command in a terminal in Fluxbox.

PS in an xterm if that matters.

That's unrelated to polkit authorizations.