Slackware 14.2 RC1 asks for root password, but didn't before 25th March, 2016
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 |
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
|
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).
|
@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 |
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 |
Same for me too.
Anyone? |
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 Code:
/dev/sdb1 /mnt auto noauto,user 0 0 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. |
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 |
For my luks partition works this but maybe root password for mount is not that bad option:
Quote:
Quote:
but I looked on default 20-plugdev-group-mount-override.rules in /etc/polkit and replace line: Quote:
to Quote:
Wait Pat fix this issue. |
Quote:
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 |
Quote:
Quote:
Code:
If you have permission errors when attempting to burn a cdrom or dvd image, |
Quote:
|
Quote:
|
Quote:
PS in an xterm if that matters. |
Quote:
|
All times are GMT -5. The time now is 03:58 PM. |