Version: 1.0.3 (using KDE 4.5.1) OS: Linux Partitionmanager should have the ability to ask for root privileges when it does a task which really requires root privileges. i.e partitionmanger can be started as user, than later on it'll ask for the password (using kdesu?) when you do operations on it. Compile time options might determine if this feature will be present or since since if it's present all the time kdesu will be a hard dependency on non-kde DEs. Reproducible: Didn't try
*** Bug 274053 has been marked as a duplicate of this bug. ***
Thanks for the wishlist entry. Like I said in the duplicate I linked to this report, I agree, but this will take a long time to implement.
*** Bug 353651 has been marked as a duplicate of this bug. ***
It might indeed be difficult to implement and I fear it might be annoying to users. Partitionmanager needs root privileges very often, e.g. it needs them when it scans devices on startup. So it will ask for root password during startup anyway. But it will also have to ask for password for a lot of other operations, e.g. mounting/unmounting, etc... So I'm not sure how useful this would be but of course I'm open to comments.
(In reply to Andrius Štikonas from comment #3) > *** Bug 353651 has been marked as a duplicate of this bug. *** I really don't understand why bug 353651 was marked a duplicate of this bug. That bug concerns the fact that there is no way to run partitionmanager as a non-root user, so that formatting external storage like SD cards assigns that storage the wrong privileges. I think partitionmanager really needs to follow gnome's Disks here. Or else it should provide a simple option for changing privileges as most would want directly from the UI (with a prompt, perhaps, after formatting asking the user if they want to do this).
My position is: use polkit, not sudo*** (In reply to Andrius Štikonas from comment #4) > It might indeed be difficult to implement and I fear it might be annoying to users. i dont think so... it would make things better for users.. 1. with polkit. first thing users would have is a native interface. Right now i use a heavily costomized design for my Plasma setup. When i start an app with (kde)su(do) it will use the "root"-user design so it dont matches my style wich is bad 2. with "always" root is still possible to open a WEBBROWSER AS ROOT! -> Check filesystem > new window opens > click on "open in external browser" and for me it opens firefox as root ... that is a big fat securitything that shouldnt be possible https://bugs.kde.org/show_bug.cgi?id=274053 3. polkit is more modern, maintained and a freedesktop standard. So nobody has to check if "does this distro support kdesu or kdesudo or gksu or gksudo or maybe nothing?" 4. it would start faster since it dont need to create a root environment (fontconfigs, pulsesetup and blah like this for user root) > Partitionmanager needs root privileges very often, e.g. it needs them > when it scans devices on startup. So it will ask for root password during > startup anyway. No Problem with that > But it will also have to ask for password for a lot of other > operations, e.g. mounting/unmounting, etc... So I'm not sure how useful this > would be but of course I'm open to comments. polkit can remember authentifications for a single app for a few minutes. to do so you policyfile needs to have <defaults> <allow_any>auth_admin_keep</allow_any> <allow_inactive>auth_admin_keep</allow_inactive> <allow_active>auth_admin_keep</allow_active> </defaults> auth_admin_keep - Like auth_admin but the authorization is kept for a brief period (e.g. five minutes). https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html the good thing is also to have more control what to run as root and what not... *** +kdesu, kdesudo
Well, this is certainly still on the wishlist but it will take some time as late Volker said. We also have to make sure not to break calamares installer, so it has to be cooperative effort of those two projects.
+1 for polkit. My original intention was to cut dependencies on non-KDE platforms.
Please note that running an application as root on X11 means that your system is potentially instantly owned. I wrote a test case for such a situation recently, more information at https://marc.info/?l=kfm-devel&m=145192452218315&w=2 You can be certain that also partitionmanager can be exploited that way. Please disallow root access and switch to polkit ASAP. This is not a wishlish, this is in fact a severe security vulnerability.
(In reply to Martin Gräßlin from comment #9) > Please note that running an application as root on X11 means that your > system is potentially instantly owned. I wrote a test case for such a > situation recently, more information at > https://marc.info/?l=kfm-devel&m=145192452218315&w=2 > > You can be certain that also partitionmanager can be exploited that way. > Please disallow root access and switch to polkit ASAP. This is not a > wishlish, this is in fact a severe security vulnerability. Dear Martin, I am not sure though whether polkit would fix that exploit path. Kate or Dolphin are usually used as a normal user and don't need root unless something very specific is done. On the other hand, KPM needs root for everything: detection of partitions, ALL write operations, etc... It often needs full write access to block devices as files anyway, so it's not clear whether polkit would be able to attain any finer granularity and prevent that security issue. So that exploit on any write operation with polkit'ed KPM would still be able to take over and delete all partitions... Or do some other nasty stuff. After all, KPM is system software to mess up with hard disks. Clearly we need to move to Wayland ASAP which is getting closer thanks to your effort... Of course polkit would improve some other aspects, like correct fonts and theme but the amount of work required here would be very non-trivial.
(In reply to Andrius Štikonas from comment #10) > Clearly we need to move to Wayland ASAP which is getting closer thanks to > your effort... which will be just another reason to go for a polkit approach. Launching root-owned gui applications just doesn't work. I just tried it for the first time and all I got were error messages (and I also expected that).
This is now in progress. First bits of KAuth support landed in kpmcore master. However, root is required in lots and lots of places, so it will still need much more work and for now kdesu is still used. (partitionmanager --dontsu now mostly detects available devices and partitions)
*** Bug 369144 has been marked as a duplicate of this bug. ***
I don't understand why it asks for a password - I put in my admin password - but it still won't start from the desktop. It was just a fluke that I happened to see something at Ubuntu Software Centre about launching it from a terminal window. Now that it's launched it scans the HDD much faster than GParted but then it won't do anything i.e. nearly all the actions are greyed out nearly all the time. And the Help file won't open, either, even though the menu item appears to be active. I'm running version 1.0.3 on Ubuntu 14 on a MacBook with Core2Duo and 4GB RAM. I've verified the HDD using Apple Disk Utility. The main functions I want that Apple Disk Utility can't provide are a (1) all aspects of manipulating ext2, ext3 and ext4, (2) moving Mac and FAT partitions.
(In reply to Barry from comment #14) > I don't understand why it asks for a password - I put in my admin password - > but it still won't start from the desktop. It was just a fluke that I > happened to see something at Ubuntu Software Centre about launching it from > a terminal window. Now that it's launched it scans the HDD much faster than > GParted but then it won't do anything i.e. nearly all the actions are greyed > out nearly all the time. And the Help file won't open, either, even though > the menu item appears to be active. > > I'm running version 1.0.3 on Ubuntu 14 on a MacBook with Core2Duo and 4GB > RAM. I've verified the HDD using Apple Disk Utility. The main functions I > want that Apple Disk Utility can't provide are a (1) all aspects of > manipulating ext2, ext3 and ext4, (2) moving Mac and FAT partitions. You need a newer version that supports Plasma 5... 1.0.3 is too old, it is 7 years old. It wouldn't even support many important features for modern hard drives like MiB aligned boundaries, GPT partitions.
Just a small update. Converting libparted backend to KAuth did not work easily, and I think former Calamares maintainer had some issues, so that change was reverted. Hence, I'm now trying another approach to get Partition Manager to run rootless. I am writing another backend for partitionmanager/kpmcore that is not libparted based but calls external programs (mostly sfdisk). Once this is done it should be easier to switch to KAuth. There are a few other places where root is required (like writing fstab file, etc).
Another update: I've got significant parts of KDE Partition Manager running without root privileges and using KAuth. For now the code is still in my scratch repository at https://git.stikonas.eu/andrius/kpmcore/src/kauth but eventually it should reach git master. At the moment not everything works. Sfdisk backend does not yet support creating new partition tables or changing partition types. There are also a few more places in KPM that don't work without root. But maybe 90% of functionality is there!
Almost all things work rootless in my branch (SMART is notable exception but SMART support is not that essential anyway, can be done later). However, I encountered another significant problem. KAuth authorization is valid for about 5 minutes. If it expires during the execution of some operation (usually moving partition, and this consists of calling many dd commands, so calls kauth helper many times) then Polkit authorization dialog is shown again. If user enters the password, then everything works fine. However, if user declines an authorization, then we'll end up with half completed move operation and most likely data loss. One way I'm thought of that can avoid this is to modify the current helper, so that it accepts the list of all commands that need to be executed. Then, user will never be asked authorization until all operations are complete. Unfortunately, to be able to do this, KPMcore would need quite a bit of refactoring in it's disk data reading/writing code (now KPM reads e.g. 10 MiB of partition data, then another function writes it to a new places and continues doing this until all partition is moved but obviously we can't store the whole partition in memory of KAuth helper). Are there any better suggestions how to workaround KAuth authorizations in the middle of the operation?
*** Bug 385525 has been marked as a duplicate of this bug. ***
The GUI of KDE Partition Manager can now run as unprivileged user. So far code is still in kauth branches of kpmcore and partitionmanager but it's getting to the state where testing and reviews would be useful. Especially, security review of the helper would be appreciated as it is used quite differently from normal KAuth helper.
Nice!
(In reply to Andrius Štikonas from comment #20) > The GUI of KDE Partition Manager can now run as unprivileged user. > > So far code is still in kauth branches of kpmcore and partitionmanager but > it's getting to the state where testing and reviews would be useful. > Especially, security review of the helper would be appreciated as it is used > quite differently from normal KAuth helper. Could you elaborate how to run without the kdesu request on app launch, please?
(In reply to abakumov.alexandr from comment #22) > (In reply to Andrius Štikonas from comment #20) > > The GUI of KDE Partition Manager can now run as unprivileged user. > > > > So far code is still in kauth branches of kpmcore and partitionmanager but > > it's getting to the state where testing and reviews would be useful. > > Especially, security review of the helper would be appreciated as it is used > > quite differently from normal KAuth helper. > > Could you elaborate how to run without the kdesu request on app launch, > please? You just run it as "partitionmanager". You'll need version 4.0 or later.
(In reply to Andrius Štikonas from comment #23) > (In reply to abakumov.alexandr from comment #22) > > (In reply to Andrius Štikonas from comment #20) > > > The GUI of KDE Partition Manager can now run as unprivileged user. > > > > > > So far code is still in kauth branches of kpmcore and partitionmanager but > > > it's getting to the state where testing and reviews would be useful. > > > Especially, security review of the helper would be appreciated as it is used > > > quite differently from normal KAuth helper. > > > > Could you elaborate how to run without the kdesu request on app launch, > > please? > > You just run it as "partitionmanager". You'll need version 4.0 or later. According to its About window, I have a version of 20.12.2. But it still requires kdesu on startup.
(In reply to Alex Abakumov from comment #24) > (In reply to Andrius Štikonas from comment #23) > > (In reply to abakumov.alexandr from comment #22) > > > (In reply to Andrius Štikonas from comment #20) > > > > The GUI of KDE Partition Manager can now run as unprivileged user. > > > > > > > > So far code is still in kauth branches of kpmcore and partitionmanager but > > > > it's getting to the state where testing and reviews would be useful. > > > > Especially, security review of the helper would be appreciated as it is used > > > > quite differently from normal KAuth helper. > > > > > > Could you elaborate how to run without the kdesu request on app launch, > > > please? > > > > You just run it as "partitionmanager". You'll need version 4.0 or later. > > According to its About window, I have a version of 20.12.2. But it still > requires kdesu on startup. That's not kdesu. That's polkit. partitionmanager now runs as unprivileged user and polkit is used to start a small non-GUI daemon running as root.
(In reply to Andrius Štikonas from comment #25) > (In reply to Alex Abakumov from comment #24) > > (In reply to Andrius Štikonas from comment #23) > > > (In reply to abakumov.alexandr from comment #22) > > > > (In reply to Andrius Štikonas from comment #20) > > > > > The GUI of KDE Partition Manager can now run as unprivileged user. > > > > > > > > > > So far code is still in kauth branches of kpmcore and partitionmanager but > > > > > it's getting to the state where testing and reviews would be useful. > > > > > Especially, security review of the helper would be appreciated as it is used > > > > > quite differently from normal KAuth helper. > > > > > > > > Could you elaborate how to run without the kdesu request on app launch, > > > > please? > > > > > > You just run it as "partitionmanager". You'll need version 4.0 or later. > > > > According to its About window, I have a version of 20.12.2. But it still > > requires kdesu on startup. > > That's not kdesu. That's polkit. partitionmanager now runs as unprivileged > user and polkit is used to start a small non-GUI daemon running as root. Oh, I think I've got it. sudo password is still required on startup not for the GUI process (partitionmanager), but for a daemon.
(In reply to Alex Abakumov from comment #26) > (In reply to Andrius Štikonas from comment #25) > > (In reply to Alex Abakumov from comment #24) > > > (In reply to Andrius Štikonas from comment #23) > > > > (In reply to abakumov.alexandr from comment #22) > > > > > (In reply to Andrius Štikonas from comment #20) > > > > > > The GUI of KDE Partition Manager can now run as unprivileged user. > > > > > > > > > > > > So far code is still in kauth branches of kpmcore and partitionmanager but > > > > > > it's getting to the state where testing and reviews would be useful. > > > > > > Especially, security review of the helper would be appreciated as it is used > > > > > > quite differently from normal KAuth helper. > > > > > > > > > > Could you elaborate how to run without the kdesu request on app launch, > > > > > please? > > > > > > > > You just run it as "partitionmanager". You'll need version 4.0 or later. > > > > > > According to its About window, I have a version of 20.12.2. But it still > > > requires kdesu on startup. > > > > That's not kdesu. That's polkit. partitionmanager now runs as unprivileged > > user and polkit is used to start a small non-GUI daemon running as root. > > Oh, I think I've got it. sudo password is still required on startup not for > the GUI process (partitionmanager), but for a daemon. Indeed. Well, we are doing a privileged operation. It's not exactly what is asked in the original report but it's better than before when the whole application was running as root (which caused various issues with dbus, wayland, etc...)
(In reply to Andrius Štikonas from comment #27) > (In reply to Alex Abakumov from comment #26) > > (In reply to Andrius Štikonas from comment #25) > > > (In reply to Alex Abakumov from comment #24) > > > > (In reply to Andrius Štikonas from comment #23) > > > > > (In reply to abakumov.alexandr from comment #22) > > > > > > (In reply to Andrius Štikonas from comment #20) > > > > > > > The GUI of KDE Partition Manager can now run as unprivileged user. > > > > > > > > > > > > > > So far code is still in kauth branches of kpmcore and partitionmanager but > > > > > > > it's getting to the state where testing and reviews would be useful. > > > > > > > Especially, security review of the helper would be appreciated as it is used > > > > > > > quite differently from normal KAuth helper. > > > > > > > > > > > > Could you elaborate how to run without the kdesu request on app launch, > > > > > > please? > > > > > > > > > > You just run it as "partitionmanager". You'll need version 4.0 or later. > > > > > > > > According to its About window, I have a version of 20.12.2. But it still > > > > requires kdesu on startup. > > > > > > That's not kdesu. That's polkit. partitionmanager now runs as unprivileged > > > user and polkit is used to start a small non-GUI daemon running as root. > > > > Oh, I think I've got it. sudo password is still required on startup not for > > the GUI process (partitionmanager), but for a daemon. > > Indeed. Well, we are doing a privileged operation. It's not exactly what is > asked in the original report but it's better than before when the whole > application was running as root (which caused various issues with dbus, > wayland, etc...) Great! Most likely, the current approach is the best that could be. It was just confusing to still see the sudo password request on startup :) Thank you so much for the clarification!