Force password to mount partition
 

The recent big update in -current has changed the way unmounted partitions can be mounted under KDE. Previously, to mount an unmounted partition required the administrator password. Now it doesn't!

This raises a security issue for me on one machine. How do I get it to revert to the previous behaviour, and demand an administrator password before allowing a partition to be mounted? What has changed?

TIA,

--
Pete

You can solve this by encrypting the slice yourself :) as there will always be an security issue any other way. Although for your case udev is the culprit and there are many solutions to this have a Google

To elaborate on what maciuszek said: anyone having physical access to your computer can do what one wants with all partitions and files unless the files be encrypted, regardless of any setting.

That's as simple as running a Slackware installer or removing a hard disk ;)

I think he's looking for the more non-technical approach to fix this... ie, he has an unencrypted partition that is not automatically mounted that used to require root access to mount, and now KDE will mount it with regular permissions.

My guess is that your fstab allows regular users to mount it by having the "user" option listed. Try changing it to nouser. If you only have "defaults" listed, it should be using nouser already, and if that is the case, it seems KDE is bypassing permissions, which is not a good thing.

Udev doesn't respect fstab does it? I would think dolphin like other file managers will respect udev for such operations.

Thanks for the replies folks. Just to elaborate - this machine is used for - amongst other things - video editing. The partition in question contains all the edit decision lists, and I just need to make it so that other ham-fisted users can't accidentally screw up these valuable files! The partition in question is commented out in fstab to prevent it being mounted at boot. Until the recent update, clicking on the partition icon to request the system to mount it would bring up a request for the admin password. Since the update, it doesn't. I've tried un-commenting it and adding "noauto,nouser", but this hasn't had the desired effect. Something else has taken over - but what?

I've restricted access to it via permissions, but I'd be happier if it wasn't mounted at all when I'm not around! The other users of the machine are non-techie, but have a habit of pushing every button under the sun when something doesn't work as expected! ;-/

I'm not bothered about MI5 or the CIA here! It doesn't need to be bomb-proof! Just enough to stop casual users doing any harm - which the root password has done very successfully up until now!

--
Pete

So, when you add "noauto,nouser", what happens? Is it mounted on boot or is it just able to be mounted by normal users within KDE?

@maciuszek, afaik, KDE will respect fstab entries if they're there. If the device isn't listed in the fstab, then it falls to udev permissions and whether the person is able to mount it by being a member of the plugdev group.

@pchristy, I doubt you'd want to remove all users from the plugdev group just to fix this (since that would prevent mounting of CDs and USB drives), but if you do remove a user from it, is that user still able to mount the partition through KDE (this is assuming you're using init 4, since I believe init 3 + startx will have that user added to plugdev automatically)?

It is my understanding that much of linux runs on an "if exists run this, if no exist run default" basis (i apologize for that incorrect and ugly code mock but I hope it gets the point across). Example - X no longer requires an xorg.conf but if you make one, it has precedence and will be used. Udev and Dolphin don't require fstab but will use them if you make one including whatever rules and switches you include.

First of all, apologies for the delayed response! There's a bit of a time difference between the USA and us here in dear old Blighty!

Bassmadrigal: with the "noauto,nouser" options, the partition can be mounted by ordinary users without any need of a password. The same is true if the line is commented out. This is a change in behaviour since the 21st April mega-update to current.

Enorbet: Yes, I understand what you are saying, and that has also been my experience up till now. However, something has changed that is making the system ignore fstab in this instance.

Removing a user from the plugdev group prevents the user from mounting the partition, but as pointed out earlier, it also prevents mounting anything else as well. Something must have changed in the udev rules somewhere that has changed the default behaviour, and made the system ignore fstab in this instance. I know very little about udev, other than a recollection of how much grief it caused me when it was originally introduced! Any pointers to the offending rule gratefully received!

--
Pete

I'm not tested that my self, but you can try changing config file /etc/polkit-1/localauthority/50-local.d/20-plugdev-group-mount-override.pkla
change lines:
ResultAny=yes
ResultInactive=yes
to
ResultAny=auth_admin
ResultInactive=auth_admin

And test if users can mount that partition without password

Bingo! That did it! Many thanks Emsi!

Trying to mount my "hidden" partition now requests the root password, yet users can still mount pen-drives without problems. Excellent!

I haven't discovered any side-effects yet, but if I do I will notify them here.

Emsi: Any chance of an explanation of what this is doing? I can sort of get my head around it, but I'm not sure why it works on drives that are there, but unmounted, on boot, but not those that are subsequently added.

Many thanks.

--
Pete

P.S. I won't mark this thread as "solved" for a day or two in case of side effects. Also I'll be interested in any comments on why this works and what is going on here.

Is the behaviour specific to kde? Do you see the same thing with XFCE/thunar?

I must confess that I haven't tried that. This is a desktop machine used for (amongst other things) video editing, so it has plenty of horsepower under the hood. I do use XFCE on my laptop when it starts to struggle, but I've never needed to with the machine in question.

I've got some catching up to do at present, but I'll give XFCE a shot in the next day or so and report back. I'll be surprised if its any different though, since it seems to be a system-level issue rather than a KDE issue.

--
Pete

Thanks Pete. I hadn't seen your reply to Emsi when I posted that last message: was trying to determine whether it was udev, or the desktop at fault.

I guess it depends on whether thunar and the xfce volume-manager use polkit in the same way kde does as to whether they'll be affected also.

Might be interesting to see wither "udisks --mount ..." also shortcuts this permissions check.

It might be worth shooting Pat an email, just in case he hasn't seen this thread. That file does not exist on 14.1, so it looks to be a new addition to -current, so it is likely just due to it being a new inclusion and trying to find sane defaults. Turns out, it resides in a folder not accessible by a normal user (sometimes it's hard to tell when using your phone to connect to your computer). The content does have ResultAny=yes ResultInactive=yes, so something else must've changed that caused this issue, however, if there are no other ill effects you can find, maybe this is the proper solution.