I have continued to use konqueror instead of dolphin because I can use profiles to have it start up connected to a remote server on specific directories. Now, it seems that that is no longer working since updating to Fedora 26. If I start it as from a command line or from a desktop object it ignores the profile option and opens as a web browser.
At least it still opens as a file manager if I make konqueror the default file manager and click on a directory object, like in folder view.
Any suggest on how I can get the profile functionality back? Is there another app I can use?
Will you please quit trying to force me to use "your way". I have been running and managing RH distributions since RH 4 and I don't need anyone telling me how to use the tools. Which were great, BTW. At least until this release.
Please continue finding a ways to make it difficult for noobs to hurt themselves, but in a way that doesn't effect those of us that know how to use the system. I have not been able to be productive since the update to Fedora 26, as I keep running into changes like this and like preventing kwrite from running as root.
Look, I know these changes are/were well intended, but that doesn't change the fact that tried and true methods suddenly, without warning, stopped working.
KDE is a GUI, and it should work like a GUI for all users and admins. If you hate GUIs for system management, let that be your problem, not mine or other's like me.
Emmett
On 07/25/2017 11:05 PM, Emmett Culley wrote:
I have continued to use konqueror instead of dolphin because I can use profiles to have it start up connected to a remote server on specific directories. Now, it seems that that is no longer working since updating to Fedora 26. If I start it as from a command line or from a desktop object it ignores the profile option and opens as a web browser.
Doing konqueror --help shows....
--profile <profile> Profile to open (DEPRECATED, IGNORED)
Maybe you should take this up with the kde.org community?
On 07/25/2017 08:17 AM, Ed Greshko wrote:
On 07/25/2017 11:05 PM, Emmett Culley wrote:
I have continued to use konqueror instead of dolphin because I can use profiles to have it start up connected to a remote server on specific directories. Now, it seems that that is no longer working since updating to Fedora 26. If I start it as from a command line or from a desktop object it ignores the profile option and opens as a web browser.
Doing konqueror --help shows....
--profile <profile> Profile to open (DEPRECATED, IGNORED)
Maybe you should take this up with the kde.org community?
I suppose I thought I was. I've been noticing konqueror functionality slip away for sometime now. So I guess this shouldn't be such a surprise. However, that functionality made my life a lot easier and is the main reason I didn't just start using dolphin.
I will take it up with kde.org, as you suggest and I should have quite awhile ago.
I cannot help but notice that KDE seems to be getting a lot like gnome in this attempt to tell us how to do our jobs. To me Linux is a complete technology stack. I use it for every day interacting with the Internet, for serious systems and web development, and for managing/serving many web apps and services. I've become used to having tools that make my work easier and faster.
Still, I suppose I shouldn't complain as a lot of people work hard to give us this great framework to work from, and I haven't found any time to contribute.
Emmett
Emmett Culley wrote:
I cannot help but notice that KDE seems to be getting a lot like gnome in this attempt to tell us how to do our jobs.
I don't think that's a fair characterization. I assume this is based on not being able to run (this) gui app as root anymore? (even though you can get similar functionality running as unprivileged user now, which is a win both security-wise and for wayland-compatibility)
As for konq deprecating support for --profile, no idea why that is, but I also don't think it fair to assign ill intent (both fedora and kde code of conduct strongly encourages everyeone to assume *good* intent, where it's unclear).
Is there more to it?
-- Rex
Rex Dieter wrote:
I don't think that's a fair characterization. I assume this is based on not being able to run (this) gui app as root anymore? (even though you can get similar functionality running as unprivileged user now, which is a win both security-wise and for wayland-compatibility)
The thing is: 1. you can't and 2. it won't tell you that you can, because there is no error dialog. The message is written to stdout, which kdesu does not forward, so the application just completely silently does not come up, a completely unacceptable user experience.
Please at least apply a patch like: https://gitlab.com/Megver83/kdebase-root-patches/raw/master/0001-Defuse-root... but I would just rip out the code block completely.
Kevin Kofler
I wrote:
Please at least apply a patch like: https://gitlab.com/Megver83/kdebase-root-patches/raw/master/0001-Defuse-root... but I would just rip out the code block completely.
PS: This is the one for Dolphin: https://gitlab.com/Megver83/kdebase-root-patches/raw/master/0001-Revert-Disa...
OpenSUSE ships both these patches by default out of the box. Please do the same in Fedora!
Kevin Kofler
Kevin Kofler wrote:
Rex Dieter wrote:
I don't think that's a fair characterization. I assume this is based on not being able to run (this) gui app as root anymore? (even though you can get similar functionality running as unprivileged user now, which is a win both security-wise and for wayland-compatibility)
The thing is:
My query was for Emmett.
- you can't and
What I described works for me when I tested it.
-- Rex
Emmett Culley wrote:
I have not been able to be productive since the update to Fedora 26, as I keep running into changes like this and like preventing kwrite from running as root.
Try: sudo sed -i -e 's/getuid/getpid/g' /usr/bin/kwrite and it should come up as root again.
And please file a bug to get that stupid user-unfriendly nonsense patched out of the Fedora package.
Kevin Kofler
On Wed, 2017-07-26 at 00:09 +0200, Kevin Kofler wrote:
Emmett Culley wrote:
I have not been able to be productive since the update to Fedora 26, as I keep running into changes like this and like preventing kwrite from running as root.
Try: sudo sed -i -e 's/getuid/getpid/g' /usr/bin/kwrite and it should come up as root again.
Running sed on an executable is unlikely to work:
$ file /usr/bin/kwrite
/usr/bin/kwrite: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=3c378cb60be1e2a76f98 1ba5c15c1096f1b6a5b5, stripped
Also, are you sure you mean 'getpid'?
poc
On 07/25/2017 07:42 PM, Patrick O'Callaghan wrote:
On Wed, 2017-07-26 at 00:09 +0200, Kevin Kofler wrote:
Emmett Culley wrote:
I have not been able to be productive since the update to Fedora 26, as I keep running into changes like this and like preventing kwrite from running as root.
Try: sudo sed -i -e 's/getuid/getpid/g' /usr/bin/kwrite and it should come up as root again.
Running sed on an executable is unlikely to work:
$ file /usr/bin/kwrite
/usr/bin/kwrite: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=3c378cb60be1e2a76f98 1ba5c15c1096f1b6a5b5, stripped
Sure it does. kwrite.test being a copy of /usr/bin/kwrite
[boutilpj@localhost ~]$ strings kwrite.test |grep getuid getuid
[boutilpj@localhost ~]$ sed -i "s/getuid/getpid/g" kwrite.test
[boutilpj@localhost ~]$ strings kwrite.test |grep getuid
[boutilpj@localhost ~]$ strings kwrite.test |grep getpid getpid
Also, are you sure you mean 'getpid'?
poc
kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org
Patrick O'Callaghan wrote:
Running sed on an executable is unlikely to work:
$ file /usr/bin/kwrite
/usr/bin/kwrite: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=3c378cb60be1e2a76f98 1ba5c15c1096f1b6a5b5, stripped
Also, are you sure you mean 'getpid'?
OK, so let me explain how this hack works (*) (I wanted to let you try and be amazed first :-p):
* The first thing to observe is that the replacement string has the same length as the string being replaced. (In fact, I only replace one character with another, but this does not even matter, as long as the length does not change.) sed actually has no issues at all with operating on binary files. The only problem is, if you change the length of the string, you break all the offsets in the executable and it will stop working. So it is extremely important that the replacement string also has 6 characters like "getuid".
* Now compare the prototypes of "getuid" and "getpid": uid_t getuid(void); pid_t getpid(void); Notice that they are almost the same, only the return type looks different at first glance. But both uid_t and pid_t are actually 32-bit integers (technically, uid_t is unsigned and pid_t is signed, but that does not matter at all at assembly level), so that does not matter. Therefore, it is safe to call one function instead of the other.
* Symbol versioning might get in your way. But if you check, you will find that the current symbol version of both "getuid" and "getpid" on x86_64 is GLIBC_2.2.5, so that will not get in your way either.
* Now look at how the check for root actually works: it does something like: if (getuid() == 0) fail; My hack changes this to: if (getpid() == 0) fail; The interesting thing is, getpid() == 0 is always false! The PID is never zero, PID 0 is reserved by the Linux kernel. So the whole check becomes a no-op and kwrite will always run.
So, all in all, I just had to look for a libc function that has a 6-letter name, a compatible prototype with getuid, and will never return 0. getpid was the perfect match. (By the way, if upstream decides to change the check to check for geteuid instead, which has 7 characters, then you can replace that with getppid, which is also never 0.)
So next time you should at least try my command before claiming that it will not work. :-) You should trust an experienced developer with assembly knowledge like me more than you do. ;-)
Note:
(*) To be sure, I have now just tested it on the kwrite binary from kwrite-17.04.1-1.fc26.x86_64.rpm, and yes, it does work – but I was almost sure it would work even before testing it. :-) "I have only proved it correct, not tried it." as Donald Knuth once wrote. ;-) But now I did try it and it works indeed.
Kevin Kofler
On 07/25/2017 05:25 PM, Kevin Kofler wrote:
Patrick O'Callaghan wrote:
Running sed on an executable is unlikely to work:
$ file /usr/bin/kwrite
/usr/bin/kwrite: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=3c378cb60be1e2a76f98 1ba5c15c1096f1b6a5b5, stripped
Also, are you sure you mean 'getpid'?
OK, so let me explain how this hack works (*) (I wanted to let you try and be amazed first :-p):
- The first thing to observe is that the replacement string has the same
length as the string being replaced. (In fact, I only replace one character with another, but this does not even matter, as long as the length does not change.) sed actually has no issues at all with operating on binary files. The only problem is, if you change the length of the string, you break all the offsets in the executable and it will stop working. So it is extremely important that the replacement string also has 6 characters like "getuid".
- Now compare the prototypes of "getuid" and "getpid":
uid_t getuid(void); pid_t getpid(void); Notice that they are almost the same, only the return type looks different at first glance. But both uid_t and pid_t are actually 32-bit integers (technically, uid_t is unsigned and pid_t is signed, but that does not matter at all at assembly level), so that does not matter. Therefore, it is safe to call one function instead of the other.
- Symbol versioning might get in your way. But if you check, you will find
that the current symbol version of both "getuid" and "getpid" on x86_64 is GLIBC_2.2.5, so that will not get in your way either.
- Now look at how the check for root actually works: it does something like:
if (getuid() == 0) fail; My hack changes this to: if (getpid() == 0) fail; The interesting thing is, getpid() == 0 is always false! The PID is never zero, PID 0 is reserved by the Linux kernel. So the whole check becomes a no-op and kwrite will always run.
So, all in all, I just had to look for a libc function that has a 6-letter name, a compatible prototype with getuid, and will never return 0. getpid was the perfect match. (By the way, if upstream decides to change the check to check for geteuid instead, which has 7 characters, then you can replace that with getppid, which is also never 0.)
So next time you should at least try my command before claiming that it will not work. :-) You should trust an experienced developer with assembly knowledge like me more than you do. ;-)
Note:
(*) To be sure, I have now just tested it on the kwrite binary from kwrite-17.04.1-1.fc26.x86_64.rpm, and yes, it does work – but I was almost sure it would work even before testing it. :-) "I have only proved it correct, not tried it." as Donald Knuth once wrote. ;-) But now I did try it and it works indeed.
Kevin Kofler
It did work indeed. Great work. Any similar "trick" to get konqueror to use the --profile option again? :-) I know, of course not.
However, Can someone direct me to where I can find the source code for konqueror? Not have profiles really cramps my productivity. Even worse that the above kwrite issue. Enough to maybe actually do something about it.
Emmett
On Tue, Jul 25, 2017 at 10:40 PM, Emmett Culley lst_manage@webengineer.com wrote:
It did work indeed. Great work. Any similar "trick" to get konqueror to use the --profile option again? :-) I know, of course not.
However, Can someone direct me to where I can find the source code for konqueror? Not have profiles really cramps my productivity. Even worse that the above kwrite issue. Enough to maybe actually do something about it.
Here's the sources: https://cgit.kde.org/konqueror.git/
On 07/25/2017 07:42 PM, Neal Gompa wrote:
On Tue, Jul 25, 2017 at 10:40 PM, Emmett Culley lst_manage@webengineer.com wrote:
It did work indeed. Great work. Any similar "trick" to get konqueror to use the --profile option again? :-) I know, of course not.
However, Can someone direct me to where I can find the source code for konqueror? Not have profiles really cramps my productivity. Even worse that the above kwrite issue. Enough to maybe actually do something about it.
Here's the sources: https://cgit.kde.org/konqueror.git/
Thanks!
On 07/25/2017 07:42 PM, Neal Gompa wrote:
On Tue, Jul 25, 2017 at 10:40 PM, Emmett Culley lst_manage@webengineer.com wrote:
It did work indeed. Great work. Any similar "trick" to get konqueror to use the --profile option again? :-) I know, of course not.
However, Can someone direct me to where I can find the source code for konqueror? Not have profiles really cramps my productivity. Even worse that the above kwrite issue. Enough to maybe actually do something about it.
Here's the sources: https://cgit.kde.org/konqueror.git/
Not correct somehow:
Cloning into 'konqueror'... fatal: repository 'https://cgit.kde.org/konqueror.git/' not found
On Tue, Jul 25, 2017 at 10:48 PM, Emmett Culley lst_manage@webengineer.com wrote:
On 07/25/2017 07:42 PM, Neal Gompa wrote:
On Tue, Jul 25, 2017 at 10:40 PM, Emmett Culley lst_manage@webengineer.com wrote:
It did work indeed. Great work. Any similar "trick" to get konqueror to use the --profile option again? :-) I know, of course not.
However, Can someone direct me to where I can find the source code for konqueror? Not have profiles really cramps my productivity. Even worse that the above kwrite issue. Enough to maybe actually do something about it.
Here's the sources: https://cgit.kde.org/konqueror.git/
Not correct somehow:
Cloning into 'konqueror'... fatal: repository 'https://cgit.kde.org/konqueror.git/' not found
The actual Git URL is: git://anongit.kde.org/konqueror.git
On Wed, 2017-07-26 at 02:25 +0200, Kevin Kofler wrote:
So next time you should at least try my command before claiming that it will not work. :-) You should trust an experienced developer with assembly knowledge like me more than you do. ;-)
That's never going to happen. I will not "try out" an *unexplained* hack running as root.
poc
Am 26.07.2017 um 12:51 schrieb Patrick O'Callaghan:
On Wed, 2017-07-26 at 02:25 +0200, Kevin Kofler wrote:
So next time you should at least try my command before claiming that it will not work. :-) You should trust an experienced developer with assembly knowledge like me more than you do. ;-)
That's never going to happen. I will not "try out" an *unexplained* hack running as root.
well, and what would have been the problem copy the binary to somwehere else as non-root and run the command there also as non-root - and hey, it would have even started from there again as non-root
Reindl Harald wrote:
well, and what would have been the problem copy the binary to somwehere else as non-root and run the command there also as non-root - and hey, it would have even started from there again as non-root
Well, to be fair, if, instead of disabling the getuid check (as it does, as I explained), the line I posted would have put something evil INSIDE the getuid check, running the binary as non-root would not have done anything bad, only running it as root would.
Kevin Kofler
On Wed, 2017-07-26 at 15:37 +0200, Kevin Kofler wrote:
Patrick O'Callaghan wrote:
That's never going to happen. I will not "try out" an *unexplained* hack running as root.
That's what QEMU/KVM is for. :-)
But now that I explained how it works, I hope that you trust my hack.
I've done plenty of binary poking in my time. The hack is not that subtle but my suspicions were aroused precisely because you hadn't explained it and it runs as root. As I don't use kwrite it's not of interest to me but I take your word that it works.
poc
On 07/26/2017 03:39 AM, Kevin Kofler wrote:
Emmett Culley wrote:
I have not been able to be productive since the update to Fedora 26, as I keep running into changes like this and like preventing kwrite from running as root.
Try: sudo sed -i -e 's/getuid/getpid/g' /usr/bin/kwrite and it should come up as root again.
And please file a bug to get that stupid user-unfriendly nonsense patched out of the Fedora package.
Agree 100%. Disallowing applications from running with root privilege is just silly.. People are killing elementary functionality for idiotic reasons!
Thanks,
Syam
Il 26 luglio 2017 17:11:01 CEST, Syam Krishnan syamcr@gmail.com ha scritto:
On 07/26/2017 03:39 AM, Kevin Kofler wrote:
Emmett Culley wrote:
I have not been able to be productive since the update to Fedora 26,
as I
keep running into changes like this and like preventing kwrite from running as root.
Try: sudo sed -i -e 's/getuid/getpid/g' /usr/bin/kwrite and it should come up as root again.
And please file a bug to get that stupid user-unfriendly nonsense
patched
out of the Fedora package.
Agree 100%. Disallowing applications from running with root privilege is just silly.. People are killing elementary functionality for idiotic reasons!
No patches and there are reasons. Focus on the feature and the ongoing work to improve it.
Luigi Toscano wrote:
No patches and there are reasons.
This "no patches" mentality needs to stop. We are not Slackware. If upstream makes a mistake and refuses to fix it, we need to fix it downstream.
OpenSUSE has working patches and ships them out of the box. Please apply their patches.
Focus on the feature and the ongoing work to improve it.
What feature? KAuth integration? It is no replacement because it does not work if you are in a rescue session that runs entirely as root. And it also does not address the critical usability bug that the error message is not discoverable because it is printed only to stdout, which goes nowhere in most cases (kdesu eats it entirely by default), instead of bringing up a GUI dialog.
Kevin Kofler
Il 27 luglio 2017 16:55:23 CEST, Kevin Kofler kevin.kofler@chello.at ha scritto:
Luigi Toscano wrote:
No patches and there are reasons.
This "no patches" mentality needs to stop. We are not Slackware. If upstream makes a mistake and refuses to fix it, we need to fix it downstream.
This is not a mistake.
OpenSUSE has working patches and ships them out of the box. Please apply their patches.
OpenSUSE will remove the patches at some point.
Focus on the feature and the ongoing work to improve it.
What feature? KAuth integration? It is no replacement because it does not work if you are in a rescue session that runs entirely as root.
Running an entire graphical session as root is no go.
And it also does not address the critical usability bug that the error message is not discoverable because it is printed only to stdout, which goes nowhere in most cases (kdesu eats it entirely by default), instead of bringing up a GUI dialog.
This can be addressed but not reverting the change.
Luigi Toscano wrote:
This is not a mistake.
It is. "kdesu kwrite" is a widely used feature, it needs to work.
OpenSUSE will remove the patches at some point.
How do you know? Have you asked them?
I think blocking root execution is a no go and will have to be patched out forever.
Running an entire graphical session as root is no go.
What else do you propose doing if you are rescuing a system with no working user account? KWrite is a very important rescue tool, being unable to use it in a rescue scenario is a no go.
And the claimed security issue that prompted the change does not even apply to KWrite, it has no embedded console.
This [the usability issue] can be addressed but not reverting the change.
Upstream refused to budge an inch even on this issue, he claims that "if you bring up a GUI dialog, you have already lost". So you would have to maintain a patch anyway. At this point, why not just use the much simpler and easier to maintain patch that removes the broken check to begin with?
In the end, a user that does not run the applications as root is at no security risk from the absence of the check, so I do not agree at all with the argument that this check is a security fix.
Kevin Kofler
On 07/27/2017 08:07 AM, Luigi Toscano wrote:
Il 27 luglio 2017 16:55:23 CEST, Kevin Kofler kevin.kofler@chello.at ha scritto:
Luigi Toscano wrote:
No patches and there are reasons.
This "no patches" mentality needs to stop. We are not Slackware. If upstream makes a mistake and refuses to fix it, we need to fix it downstream.
This is not a mistake.
OpenSUSE has working patches and ships them out of the box. Please apply their patches.
OpenSUSE will remove the patches at some point.
Focus on the feature and the ongoing work to improve it.
What feature? KAuth integration? It is no replacement because it does not work if you are in a rescue session that runs entirely as root.
Running an entire graphical session as root is no go.
And it also does not address the critical usability bug that the error message is not discoverable because it is printed only to stdout, which goes nowhere in most cases (kdesu eats it entirely by default), instead of bringing up a GUI dialog.
This can be addressed but not reverting the change.
Did you read anywhere in this thread that there is a need to run a GUI as root? Not you didn't.
Those of us that are "complaining" are "power users" (not noobs) and are only looking to be productive. By assuming that we all need to operate at some nonsensical lowest common denominator, you have seriously reduced our productivity.
I personally resent being told how to operate. If that was OK with me I'd still be using windows.
Sure, make it impossible to start the GUI as root. I haven't done that since RH 4. However, I do need to interact with system level files as part of getting my work done, and the latest changes to the GUI (KDE) I use to get work done is now working against me.
Because someone wants to protect noobs?
Emmett
Emmett Culley wrote:
Did you read anywhere in this thread that there is a need to run a GUI as root? Not you didn't.
[…]
Sure, make it impossible to start the GUI as root.
Actually, I would also consider that a no go, for the same reasons that banning it for KWrite is a no go: if I as the user decide that I need it, that's my problem, and the software ought to do what I told it to do. An example scenario is rescuing a system where the only unprivileged user account is not working.
But I agree with the remainder of your message.
Kevin Kofler
On 07/27/2017 08:27 AM, Kevin Kofler wrote:
Emmett Culley wrote:
Did you read anywhere in this thread that there is a need to run a GUI as root? Not you didn't.
[…]
Sure, make it impossible to start the GUI as root.
Actually, I would also consider that a no go, for the same reasons that banning it for KWrite is a no go: if I as the user decide that I need it, that's my problem, and the software ought to do what I told it to do. An example scenario is rescuing a system where the only unprivileged user account is not working.
But I agree with the remainder of your message.
Kevin Kofler
Actually, I meant pretty much what you wrote. Make it difficult to start a GUI as root, so that you need to learn something about the system to alter that configuration. For non-noobs, making that change would be just part of setting up a new system. Like removing network manage and setting up network scrips manually for fixed (non-portable) machines.
Emmett
Il 27 luglio 2017 17:21:31 CEST, Emmett Culley lst_manage@webengineer.com ha scritto:
On 07/27/2017 08:07 AM, Luigi Toscano wrote:
Il 27 luglio 2017 16:55:23 CEST, Kevin Kofler
kevin.kofler@chello.at ha scritto:
Luigi Toscano wrote:
No patches and there are reasons.
This "no patches" mentality needs to stop. We are not Slackware. If upstream makes a mistake and refuses to fix it, we need to fix it downstream.
This is not a mistake.
OpenSUSE has working patches and ships them out of the box. Please apply their patches.
OpenSUSE will remove the patches at some point.
Focus on the feature and the ongoing work to improve it.
What feature? KAuth integration? It is no replacement because it
does
not work if you are in a rescue session that runs entirely as root.
Running an entire graphical session as root is no go.
And it also does not address the critical usability bug that the error message
is
not discoverable because it is printed only to stdout, which goes
nowhere
in most cases (kdesu eats it entirely by default), instead of bringing
up
a GUI dialog.
This can be addressed but not reverting the change.
Did you read anywhere in this thread that there is a need to run a GUI as root? Not you didn't.
Those of us that are "complaining" are "power users" (not noobs) and are only looking to be productive. By assuming that we all need to operate at some nonsensical lowest common denominator, you have seriously reduced our productivity.
I personally resent being told how to operate. If that was OK with me I'd still be using windows.
Sure, make it impossible to start the GUI as root. I haven't done that since RH 4. However, I do need to interact with system level files as part of getting my work done, and the latest changes to the GUI (KDE) I use to get work done is now working against me.
You want to edit files where the access requires higher privileges. This will be possible wheb the ongoing Google Summer of Code which is working on the missing bits in KIO will be merged in master.
Because someone wants to protect noobs?
No, because they will be able to edit privileged files. It is a security problem.
On Thu, Jul 27, 2017 at 11:50 AM, Luigi Toscano luigi.toscano@tiscali.it wrote:
No, because they will be able to edit privileged files. It is a security problem.
I don't really have a strong opinion on this thread one way or the other, but... how is it a security problem if a user who has root access to the system anyway wants to edit privileged files?
I understand the argument that running graphical applications as root is generally not a good idea, and I understand the desire to protect against that, but this logic doesn't seem to follow to me. Perhaps I'm not understanding the point you are trying to make here?
Ben Rosser
Il 27 luglio 2017 18:02:45 CEST, Ben Rosser rosser.bjr@gmail.com ha scritto:
On Thu, Jul 27, 2017 at 11:50 AM, Luigi Toscano luigi.toscano@tiscali.it wrote:
No, because they will be able to edit privileged files. It is a
security problem.
I don't really have a strong opinion on this thread one way or the other, but... how is it a security problem if a user who has root access to the system anyway wants to edit privileged files?
The user need to provide a password to access the privileged files, and the only operation allowed will be the requested one against that file. Running an entire application as root expose all the possible operations:
https://blog.martin-graesslin.com/blog/2017/02/editing-files-as-root/
On 07/27/2017 09:39 AM, Luigi Toscano wrote:
Il 27 luglio 2017 18:02:45 CEST, Ben Rosser rosser.bjr@gmail.com ha scritto:
On Thu, Jul 27, 2017 at 11:50 AM, Luigi Toscano luigi.toscano@tiscali.it wrote:
No, because they will be able to edit privileged files. It is a
security problem.
I don't really have a strong opinion on this thread one way or the other, but... how is it a security problem if a user who has root access to the system anyway wants to edit privileged files?
The user need to provide a password to access the privileged files, and the only operation allowed will be the requested one against that file. Running an entire application as root expose all the possible operations:
https://blog.martin-graesslin.com/blog/2017/02/editing-files-as-root/
Yes it does expose privileged files, and that would be the point. It is enough to ask for a password to run the app, like "kdesu konqueror". Forcing me to enter a strong pass phrase with every operation is just silly. Especially as I would have had to enter my pass phrase to open to app in the first place.
You have just added a completely unnecessary hindrance to me getting my work done. And you have probably forced me to use weak passwords in order to get work done.
Emmett
Luigi Toscano wrote:
The user need to provide a password to access the privileged files, and the only operation allowed will be the requested one against that file. Running an entire application as root expose all the possible operations:
https://blog.martin-graesslin.com/blog/2017/02/editing-files-as-root/
I understand the argument, I just don't agree that it makes sense.
Upstream's point is that this opens up a privilege escalation possibility for malicious code running under your account. But let me point out that:
1. if you have malicious code running under your account to begin with, you have already lost. The malware can already read, encrypt and/or wipe all your personal data, which is the really important one (not the system files owned by root), it does not need ANY privilege escalation exploit for that.
2. if you are in a root session, the malicious code is already running as root and so there is no privilege escalation vulnerability at all. Yet, the check also prevents running the application in that context.
3. the privilege escalation is only possible if the user already voluntarily started the application as root and took the risk. The mere fact of allowing it is NOT a vulnerability. Therefore, consider the 2 cases: 3a) The user does not want or need to run the application as root. Then the change will not have ANY impact on the user. There is NO security issue either way. 3b) The user wants or needs to run the application as root. Then the change breaks the application for the user!
4. by refusing to run as root, you just make the user run another application without such a check instead, which has the exact same issue. Users will NOT use sudoedit or KAuth or whatever upstream wants to force them to use. So what security benefit does this change really bring?
In the end, this only removes power from the user and brings no practical security benefit whatsoever. Free Software is not about having the computer dictate what the user can do!
Kevin Kofler
Kevin Kofler composed on 2017-07-27 20:07 (UTC+0200):
In the end, this only removes power from the user and brings no practical security benefit whatsoever. Free Software is not about having the computer dictate what the user can do!
Seriously. Limiting what a superuser can do is oxymoronic. If a superuser cannot do something, it /only/ follows that an ordinary user would neither be able to do that something. A superuser is like a god, possessor of complete authority, power and control, including the ability to delete the entire installation and replace it with a non-broken one.
-
Ben Rosser -
Ed Greshko -
Emmett Culley -
Felix Miata -
Kevin Kofler -
Luigi Toscano -
Neal Gompa -
Patrick Boutilier -
Patrick O'Callaghan -
Reindl Harald -
Rex Dieter -
Syam Krishnan