FC12/KDE
Were is Konqueror in Root ?
Konqueror can only be run as User.
Jim wrote:
FC12/KDE
Were is Konqueror in Root ?
Konqueror can only be run as User.
Same with gnome. Someone's misguided attempt to secure the system. It's dead easy to install a system with no means to login to a GUI and configure stuff.
All you need do is install sans user account.
John Summerfield wrote:
Same with gnome. Someone's misguided attempt to secure the system. It's dead easy to install a system with no means to login to a GUI and configure stuff.
All you need do is install sans user account.
I'd suggest that anyone who sets up a system without any user accounts _and_ somehow needs a GUI to configure the system _and_ can't manage to figure out the settings to change so they can login as root should probably not be pretending to be a competent administrator.
Are there not enough examples from Windows of why it's a terrible idea to run with full administrator privileges -- especially software like web browsers?
On 11/01/2009 01:26 AM, Todd Zullinger wrote:
John Summerfield wrote:
Same with gnome. Someone's misguided attempt to secure the system. It's dead easy to install a system with no means to login to a GUI and configure stuff.
All you need do is install sans user account.
I'd suggest that anyone who sets up a system without any user accounts _and_ somehow needs a GUI to configure the system _and_ can't manage to figure out the settings to change so they can login as root should probably not be pretending to be a competent administrator.
Are there not enough examples from Windows of why it's a terrible idea to run with full administrator privileges -- especially software like web browsers?
Look guys, I didn't ask for a Lecture on how to do things your way, I just ask where is Konqueror in Root.
I'd suggest that anyone who sets up a system without any user accounts _and_ somehow needs a GUI to configure the system _and_ can't manage to figure out the settings to change so they can login as root should probably not be pretending to be a competent administrator.
I guess the last part is not correct - he *can* login as root, but *can not* run Konqueror as root ... that's a difference
oh, and also the original post was not about installing without ordinary user accounts
well, but this is not the point - the point is, that someone who supposes he's smarter than the others just disables a possibility for the others
please, stop protecting other people from themselves - if they want to risk being hurt, just let them get hurt ...
I've got a usecase - what about using Konqueror to configure CUPS
what is the security difference between doing $ su - # konqueror localhost:631
and
$ konqueror localhost:631 <supply root password to konqueror when asked for>
?
in the first case, if the attacker gets in control of Konqueror, he can do rm -rf / directly; in the latter, he can capture root password ... which may (or may not) be more valuable
Are there not enough examples from Windows of why it's a terrible idea to run with full administrator privileges -- especially software like web browsers?
I do not think that using Windows as an argument is worth here
and do not forget that Konqueror is also a file browser, not just web browser (oh, does everyone really has to do "cd /etc; vi someconfigfile" in the text console?)
K.
On 11/2/2009 8:26 AM, Karel Volný wrote:
I'd suggest that anyone who sets up a system without any user accounts _and_ somehow needs a GUI to configure the system _and_ can't manage to figure out the settings to change so they can login as root should probably not be pretending to be a competent administrator.
I guess the last part is not correct - he *can* login as root, but *can not* run Konqueror as root ... that's a difference
oh, and also the original post was not about installing without ordinary user accounts
well, but this is not the point - the point is, that someone who supposes he's smarter than the others just disables a possibility for the others
please, stop protecting other people from themselves - if they want to risk being hurt, just let them get hurt ...
I've got a usecase - what about using Konqueror to configure CUPS
what is the security difference between doing $ su - # konqueror localhost:631
and
$ konqueror localhost:631
<supply root password to konqueror when asked for>
?
in the first case, if the attacker gets in control of Konqueror, he can do rm -rf / directly; in the latter, he can capture root password ... which may (or may not) be more valuable
Are there not enough examples from Windows of why it's a terrible idea to run with full administrator privileges -- especially software like web browsers?
I do not think that using Windows as an argument is worth here
and do not forget that Konqueror is also a file browser, not just web browser (oh, does everyone really has to do "cd /etc; vi someconfigfile" in the text console?)
You, sir, are advocating one of the major 'stupid Windows users' arguments for Linux. Run as root.
The point is, I believe, that to disable root is considered a good thing. Those that disagree with that thought and wish to open their system that way are free to do so. Those that do not know *how* to do that probably should *not* do that.
Makes sense to me.
David wrote:
and do not forget that Konqueror is also a file browser, not just web browser (oh, does everyone really has to do "cd /etc; vi someconfigfile" in the text console?)
You, sir, are advocating one of the major 'stupid Windows users' arguments for Linux. Run as root.
The point is, I believe, that to disable root is considered a good thing. Those that disagree with that thought and wish to open their system that way are free to do so. Those that do not know *how* to do that probably should *not* do that.
Makes sense to me.
I don't think the people at Red Hat are entirely stupid, though I disagree with them on some matters and I think that preventing root from using GUIs is futile and misguided, especially as a good proportion of the software must be run with root privilege. Think, RH the configuration tools run with root privilege. That means all of GTK, python, perl and X,
RH does not disable the root account, it just prevents it from logging in to a GUI.
To do the job properly, it should (at least) allow the root account to be disabled entirely, and insist that if that's done the installer also creates an account that can be used for administration. Using sudo, not su.
Ubuntu has done that from day one (but not at the user's option) and it works fine.
Above I refer to "Red Hat" because it was on RHEL-clone that I mas most recently tripped up. I don't _know_ of any relevant way Fedora differs.
On 11/02/2009 09:31 PM, John Summerfield wrote:
To do the job properly, it should (at least) allow the root account to be disabled entirely, and insist that if that's done the installer also creates an account that can be used for administration. Using sudo, not su.
Sudo doesn't allow fine grained access. PolicyKit (via pkexec) does, which is why it is developed and favored by Fedora.
Rahul
On Tue, 2009-11-03 at 00:01 +0800, John Summerfield wrote:
I don't think the people at Red Hat are entirely stupid, though I disagree with them on some matters and I think that preventing root from using GUIs is futile and misguided, especially as a good proportion of the software must be run with root privilege. Think, RH the configuration tools run with root privilege. That means all of GTK, python, perl and X,
That's exactly why we are heavily supporting the development and integration of PolicyKit, which solves precisely that problem.
On Monday 02 of November 2009 14:54:08 David wrote:
You, sir, are advocating one of the major 'stupid Windows users' arguments for Linux. Run as root.
um, I still do not get it - why do you keep talking about Windows? ... it is Fedora here
and you *need* to use root to achieve some things, like editing configfiles or so
so, what is wrong about using Konqueror as root?
is, for example, Midnight commander any better? - or typing "cd something; ls; cd something; ls ..." in bash?
is it just because you hate Konqueror, or you hate GUI in general?
no one ever on this thread was talking about "doing everything as root" which seems to be the thing you argue against
The point is, I believe, that to disable root is considered a good thing.
"is considered"? - no, *you* and a few others consider ... but there is also a number of people that disagree - do not promote your personal opinion to the ultimate truth(tm)
you want to babysit the others
I want the freedom
Those that disagree with that thought and wish to open their system that way are free to do so.
no, they are not free - they have to overcome the obstacles put by the other group
Those that do not know *how* to do that probably should *not* do that.
Makes sense to me.
to me, it does not - I really do not understand why should I study tons of TFM just to learn how to allow me to edit a configfile or whatever
K.
On 11/4/2009 7:47 AM, Karel Volný wrote:
On Monday 02 of November 2009 14:54:08 David wrote:
You, sir, are advocating one of the major 'stupid Windows users' arguments for Linux. Run as root.
um, I still do not get it - why do you keep talking about Windows? ... it is Fedora here
and you *need* to use root to achieve some things, like editing configfiles or so
so, what is wrong about using Konqueror as root?
is, for example, Midnight commander any better? - or typing "cd something; ls; cd something; ls ..." in bash?
is it just because you hate Konqueror, or you hate GUI in general?
no one ever on this thread was talking about "doing everything as root" which seems to be the thing you argue against
The point is, I believe, that to disable root is considered a good thing.
"is considered"? - no, *you* and a few others consider ... but there is also a number of people that disagree - do not promote your personal opinion to the ultimate truth(tm)
you want to babysit the others
I want the freedom
Those that disagree with that thought and wish to open their system that way are free to do so.
no, they are not free - they have to overcome the obstacles put by the other group
Those that do not know *how* to do that probably should *not* do that.
Makes sense to me.
to me, it does not - I really do not understand why should I study tons of TFM just to learn how to allow me to edit a configfile or whatever
set by step volumes (tons?) of TFM
1: login in as user. 2: as user open a terminal window 3: switch from the user to root using steps 3a and 3b 3a: type su - <enter> at the prompt 3b: enter root's password <enter> at the prompt 4: type konqueror & <enter> (the & lets you keep the terminal) 5: move through the tree to the configuration file location 6: open the file and edit it 7: save the file as edited 8: logout as root and then logout as user or just close the terminal window.
Simple enough for ya? This is Linux 101 stuff here friend.
...
set by step volumes (tons?) of TFM
1: login in as user. 2: as user open a terminal window 3: switch from the user to root using steps 3a and 3b 3a: type su - <enter> at the prompt 3b: enter root's password <enter> at the prompt 4: type konqueror & <enter> (the & lets you keep the terminal)
how do I understand the original question, this step 4 didn't work for the original inquirer; and still, he is unable to use the alternative way via kdesu
and some said that it is okay that Konqueror can't be run as root
and you said "The point is, I believe, that to disable root is considered a good thing."
so keep on topic and explain to me, how do I do step 3 if root is disabled, and what is it good for?
oh, and if you are really bored, you can answer my previous question that you have chosen to ignore in your reply - how are the Windows related, when we are talking about doing administrative tasks using the root account in Fedora, and not about using the Administrator account to do daily tasks in Windows?
K.
On 11/4/2009 8:46 AM, Karel Volný wrote:
...
set by step volumes (tons?) of TFM
1: login in as user. 2: as user open a terminal window 3: switch from the user to root using steps 3a and 3b 3a: type su - <enter> at the prompt 3b: enter root's password <enter> at the prompt 4: type konqueror & <enter> (the & lets you keep the terminal)
how do I understand the original question, this step 4 didn't work for the original inquirer; and still, he is unable to use the alternative way via kdesu
and some said that it is okay that Konqueror can't be run as root
and you said "The point is, I believe, that to disable root is considered a good thing."
so keep on topic and explain to me, how do I do step 3 if root is disabled, and what is it good for?
What release of Fedora are you using? I ask because Dolphin is a replacement file handler for Konqueror.
Another question. When you try to follow my instructions (above) are you misspelling the name? I ask because konqueror is spelled just like that. konqueror. All lower case letters. Since Linux is a case sensitive OS the names 'konqueror' and 'Konqueror' are different. Several times you have used the name with the capital 'K'. That won't work.
I ask because I use GNOME for my desktop and I had to install KDE, since it was not installed, to check this. From a terminal the name
konqueror opens konqueror
the name Konqueror
fails with
[root] /root/Desktop # Konqueror& bash: Konqueror: command not found [1] 2076 [1]+ Exit 127 Konqueror [root] /root/Desktop #
But like I said I think what you need to use is Dolphin. *AND* it is spelled with all lower case letters too. dolphin
And "root is disabled" is not true. The *GUI login* for root is disabled but the root account is still there. It has to be there.
oh, and if you are really bored, you can answer my previous question that you have chosen to ignore in your reply - how are the Windows related, when we are talking about doing administrative tasks using the root account in Fedora, and not about using the Administrator account to do daily tasks in Windows?
Actually I did not answer because it does not really relate to *your* major question.
I mentioned Windows because older versions, and newer ones that are installed incorrectly, can be setup so that the user has Administrator privileges when logged in. That allows any malware to run with full access to the whole system. And you really don't want that. If, in Linux, you run one application as 'root' (as I described) that is the only place that malware can run. In that terminal. If you run the whole system as root, a GUI login as root for example, you open the whole system to malware.
Modern, and correctly, installed Windows has an Administrator and users. Users are limited as to what they can do. Which is a good thing. And it is also the better way to run your Linux system.
let's stop it, there seems to be a communication barrier we are unable to overcome
Konqeuror is no worse[*] filemanager than Dolphin, suggesting usage of Dolphin is a step aside ... that direction of discussion leads to nowhere, and we are already pretty offtopic
[*] of course depends on how do you set the criteria
once again thanks to Adam Williamson for clarifying the source of the original problem, and sorry for me not being able to keep my mouth shut
K.
On Wednesday 04 of November 2009 16:57:07 David wrote:
On 11/4/2009 8:46 AM, Karel Volný wrote:
...
set by step volumes (tons?) of TFM
1: login in as user. 2: as user open a terminal window 3: switch from the user to root using steps 3a and 3b 3a: type su - <enter> at the prompt 3b: enter root's password <enter> at the prompt 4: type konqueror & <enter> (the & lets you keep the terminal)
how do I understand the original question, this step 4 didn't work for the original inquirer; and still, he is unable to use the alternative way via kdesu
and some said that it is okay that Konqueror can't be run as root
and you said "The point is, I believe, that to disable root is considered a good thing."
so keep on topic and explain to me, how do I do step 3 if root is disabled, and what is it good for?
What release of Fedora are you using? I ask because Dolphin is a replacement file handler for Konqueror.
Another question. When you try to follow my instructions (above) are you misspelling the name? I ask because konqueror is spelled just like that. konqueror. All lower case letters. Since Linux is a case sensitive OS the names 'konqueror' and 'Konqueror' are different. Several times you have used the name with the capital 'K'. That won't work.
I ask because I use GNOME for my desktop and I had to install KDE, since it was not installed, to check this. From a terminal the name
konqueror opens konqueror
the name Konqueror
fails with
[root] /root/Desktop # Konqueror& bash: Konqueror: command not found [1] 2076 [1]+ Exit 127 Konqueror [root] /root/Desktop #
But like I said I think what you need to use is Dolphin. *AND* it is spelled with all lower case letters too. dolphin
And "root is disabled" is not true. The *GUI login* for root is disabled but the root account is still there. It has to be there.
oh, and if you are really bored, you can answer my previous question that you have chosen to ignore in your reply - how are the Windows related, when we are talking about doing administrative tasks using the root account in Fedora, and not about using the Administrator account to do daily tasks in Windows?
Actually I did not answer because it does not really relate to *your* major question.
I mentioned Windows because older versions, and newer ones that are installed incorrectly, can be setup so that the user has Administrator privileges when logged in. That allows any malware to run with full access to the whole system. And you really don't want that. If, in Linux, you run one application as 'root' (as I described) that is the only place that malware can run. In that terminal. If you run the whole system as root, a GUI login as root for example, you open the whole system to malware.
Modern, and correctly, installed Windows has an Administrator and users. Users are limited as to what they can do. Which is a good thing. And it is also the better way to run your Linux system.
Is this properly a Fedora or an upstream issue?
If the KDE/Konqueror code upstream contains prejudice against operation as root, then Fedora has no finger in this pie: it simply packaged the code. The "allow/disallow root" argument belongs upstream; it is not a Fedora issue.
If Fedora has modified the upstream code to create this aversion to run as root, then there are two questions:
1. Is it approprate to do this? This thread already contains enough comments to strongly suggest there will be no concensus about this.
2. Has this been done in a thoughtful way? It may be an appropriate default setting (avoids risks Fedora thinks users may not expect or understand), but it should be possible to modify this default so root operation of Konqueror is possible.
If one builds Konqueror from upstream source, does it balk when invoked as root? If it does, argue upstream. If it does not, look further into what Fedora has done, but you now have a Konqueror you can use as root.
On 11/4/2009 11:09 AM, Richard Ryniker wrote:
Is this properly a Fedora or an upstream issue?
If the KDE/Konqueror code upstream contains prejudice against operation as root, then Fedora has no finger in this pie: it simply packaged the code. The "allow/disallow root" argument belongs upstream; it is not a Fedora issue.
If Fedora has modified the upstream code to create this aversion to run as root, then there are two questions:
- Is it approprate to do this? This thread already contains enough
comments to strongly suggest there will be no concensus about this.
- Has this been done in a thoughtful way? It may be an appropriate
default setting (avoids risks Fedora thinks users may not expect or understand), but it should be possible to modify this default so root operation of Konqueror is possible.
If one builds Konqueror from upstream source, does it balk when invoked as root? If it does, argue upstream. If it does not, look further into what Fedora has done, but you now have a Konqueror you can use as root.
Take a deep breath friend. :-)
The 'no root GUI login' is from GDM and is a GNOME upstream setting/default.
Konqueror, as provided by Fedora, can be run by the root user.
On Wed, 2009-11-04 at 11:09 -0500, Richard Ryniker wrote:
Is this properly a Fedora or an upstream issue?
If the KDE/Konqueror code upstream contains prejudice against operation as root, then Fedora has no finger in this pie: it simply packaged the code. The "allow/disallow root" argument belongs upstream; it is not a Fedora issue.
If Fedora has modified the upstream code to create this aversion to run as root, then there are two questions:
- Is it approprate to do this? This thread already contains enough
comments to strongly suggest there will be no concensus about this.
- Has this been done in a thoughtful way? It may be an appropriate
default setting (avoids risks Fedora thinks users may not expect or understand), but it should be possible to modify this default so root operation of Konqueror is possible.
If one builds Konqueror from upstream source, does it balk when invoked as root? If it does, argue upstream. If it does not, look further into what Fedora has done, but you now have a Konqueror you can use as root.
I think a lot of people are arguing at cross-purposes here. Let me try and clarify.
No-one believes you should not be able to run Konqueror as root, as far as I can tell.
What some people are saying is that you should not be able to log in to the entire graphical desktop from the graphical login manager as root, which is arguably true, but entirely irrelevant to the main issue here.
Most importantly, there is actually a big bug at the root of this discussion, it's filed and marked as a release blocker and there's an updated selinux-policy available that ought to fix it. The bug is https://bugzilla.redhat.com/show_bug.cgi?id=532748 , the fix is in http://koji.fedoraproject.org/koji/buildinfo?buildID=139739 . The bug stopped the 'kdesu' command working, which is what KDE internally uses whenever it wants to run something as root, and what some users are used to invoking directly to run KDE things as root. I suspect those who hit this bug were trying to run 'kdesu konqueror', and it wasn't working because of this bug. Others ran 'su -; konqueror', saw that it worked, and were confused.
Does that hopefully clear most things up?
On Wednesday 04 of November 2009 19:15:50 Adam Williamson wrote:
What some people are saying is that you should not be able to log in to the entire graphical desktop from the graphical login manager as root, which is arguably true, but entirely irrelevant to the main issue here.
what I say is that you should be able to do that at your will
you should be warned that this is not a good idea, and this is the line what the software (thus its authors) should not cross
as it was said by John: "My security is my responsibility, not my vendor's. The vendor's responsibility is to provide tools and documentation.
Neither you nor my vendors understand my particular requirements and circumstances, and lacking that information you are poorly qualified to judge."
I'm sorry for my overreaction, but the issue is quite sensitive to me due its analogy to other things happening all over the world (and touching me) - "for our safety"
this really does not belong on this list; but my will is weak and I couldn't resist to react when the original writer was told not to use GUI as root at all ... I'll try better next time not to waste your time
Most importantly, there is actually a big bug at the root of this discussion, it's filed and marked as a release blocker and there's an updated selinux-policy available that ought to fix it. The bug is https://bugzilla.redhat.com/show_bug.cgi?id=532748 , the fix is in http://koji.fedoraproject.org/koji/buildinfo?buildID=139739 . The bug stopped the 'kdesu' command working,
...
thankyou - this is exactly the piece of information that was missing to answer the original post ... Adam ruleZZ again! ;-)
K.
On 11/05/2009 07:29 AM, Karel Volný wrote:
On Wednesday 04 of November 2009 19:15:50 Adam Williamson wrote:
What some people are saying is that you should not be able to log in to the entire graphical desktop from the graphical login manager as root, which is arguably true, but entirely irrelevant to the main issue here.
what I say is that you should be able to do that at your will
you should be warned that this is not a good idea, and this is the line what the software (thus its authors) should not cross
as it was said by John: "My security is my responsibility, not my vendor's. The vendor's responsibility is to provide tools and documentation.
Neither you nor my vendors understand my particular requirements and circumstances, and lacking that information you are poorly qualified to judge."
I'm sorry for my overreaction, but the issue is quite sensitive to me due its analogy to other things happening all over the world (and touching me) - "for our safety"
this really does not belong on this list; but my will is weak and I couldn't resist to react when the original writer was told not to use GUI as root at all ... I'll try better next time not to waste your time
Most importantly, there is actually a big bug at the root of this discussion, it's filed and marked as a release blocker and there's an updated selinux-policy available that ought to fix it. The bug is https://bugzilla.redhat.com/show_bug.cgi?id=532748 , the fix is in http://koji.fedoraproject.org/koji/buildinfo?buildID=139739 . The bug stopped the 'kdesu' command working,
...
thankyou - this is exactly the piece of information that was missing to answer the original post ... Adam ruleZZ again! ;-)
K.
Would someone explain to me what is the detrimental difference between a Gui or command line, logging in to root from the same box .
Most of the people that over reacted to question was they looked at Konqueror as a Web Browser, not realizing it is also a File Manager.
Konqueror also has a very nice feature called "fish" that allow users to move files from one computer to another, using SSH. fish://user@192.168.1.100:/home/user
Rules to answering this question:
1. Don't over react to question. 2. I'm not talking about using a Web Browser in this case, because that is just plain stupid.
2009/11/5 Jim mickeyboa@sbcglobal.net:
- Don't over react to question.
- I'm not talking about using a Web Browser in this case, because that is
just plain stupid.
3. This thread starts to go south. So please stop it now.
On Thu, Nov 05, 2009 at 12:14:44PM -0500, Jim wrote:
Would someone explain to me what is the detrimental difference between a Gui or command line, logging in to root from the same box .
Complexity. The more programs are involved the harder they become to secure. With specialized tools that can be manageable and you can tell that a trade-off of a small GUI is worth it but you are talking about a "kitchen sink" application here.
Most of the people that over reacted to question was they looked at Konqueror as a Web Browser, not realizing it is also a File Manager.
And also..., and also..., and ... Here is the issue. "Big" web browsers are complicated beast and chances for forgotten "dark corners" and unwanted/unexpected interactions grow exponentially with size. Root should be much more careful as effects of a hypothetical compromise are far reaching.
- I'm not talking about using a Web Browser in this case, because that
is just plain stupid.
In some sense you just answered your own question. You do use a web browser too as you really do not have good ways to control what such thing is doing behind your back.
Michal
Michal Jaegermann wrote:
On Thu, Nov 05, 2009 at 12:14:44PM -0500, Jim wrote:
Would someone explain to me what is the detrimental difference between a Gui or command line, logging in to root from the same box .
Complexity. The more programs are involved the harder they become to secure. With specialized tools that can be manageable and you can tell that a trade-off of a small GUI is worth it but you are talking about a "kitchen sink" application here.
Most of the people that over reacted to question was they looked at Konqueror as a Web Browser, not realizing it is also a File Manager.
And also..., and also..., and ... Here is the issue. "Big" web browsers are complicated beast and chances for forgotten "dark corners" and unwanted/unexpected interactions grow exponentially with size. Root should be much more careful as effects of a hypothetical compromise are far reaching.
You only need to look at the guano that is Internet Explorer to prove how incestuous and dangerous a web browser/file manager/media manager/ swiss army knife app can get. Other GUI apps can be just as detrimental. A security hole in any of them can be disastrous.
These are the main reasons why the default for F10-F12 is to not permit the root user to log in as a GUI user--specifically to keep people from shooting themselves in the foot. If you really need a GUI for certain tasks you want root to do, the "bring up a command line, 'su -' in it and run the GUI app you want from there" is a reasonable compromise. If you really, really want root to log in as a GUI, follow the instructions in the Wiki. It's not hard to do.
I've been a Linux admin for well over 15 years and I've yet to see when I really _need_ root to have a GUI. It's nice on occasion, but you use it (and anything as root) at your own risk. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - NEWS FLASH! Intelligence of mankind decreasing! Details at... - - uh, when, uh, the little hand is, uh, on the... Aw, NUTS! - ----------------------------------------------------------------------
On Thu, 2009-11-05 at 10:45 -0800, Rick Stevens wrote:
I've been a Linux admin for well over 15 years and I've yet to see when I really _need_ root to have a GUI.
The only convincing use case I've ever come up with is resizing the /home partition using a graphical partition tool; you can't do that with su from a user account because the partition will obviously be busy. =) but it's sufficiently niche that 'just run startx from runlevel 3' is really enough to cover it. or, y'know, 'use a live CD'.
Adam Williamson wrote:
On Thu, 2009-11-05 at 10:45 -0800, Rick Stevens wrote:
I've been a Linux admin for well over 15 years and I've yet to see when I really _need_ root to have a GUI.
The only convincing use case I've ever come up with is resizing the /home partition using a graphical partition tool; you can't do that with su from a user account because the partition will obviously be busy. =) but it's sufficiently niche that 'just run startx from runlevel 3' is really enough to cover it. or, y'know, 'use a live CD'.
I suppose I'm old school, but I have a tendency to not resize partitions on a machine in any multiuser state. Just don't trust it. LVM and such do make it more reliable, but I'd only do it in single user mode, so GUI is out anyway. Belt and braces, belt and braces (as far as futzing with disks on live systems is concerned anyway)...
---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks@nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Do not taunt the sysadmins, for they are subtle and quick to anger - ----------------------------------------------------------------------
On Fri, 2009-11-06 at 13:23 -0800, Rick Stevens wrote:
Adam Williamson wrote:
On Thu, 2009-11-05 at 10:45 -0800, Rick Stevens wrote:
I've been a Linux admin for well over 15 years and I've yet to see when I really _need_ root to have a GUI.
The only convincing use case I've ever come up with is resizing the /home partition using a graphical partition tool; you can't do that with su from a user account because the partition will obviously be busy. =) but it's sufficiently niche that 'just run startx from runlevel 3' is really enough to cover it. or, y'know, 'use a live CD'.
I suppose I'm old school, but I have a tendency to not resize partitions on a machine in any multiuser state. Just don't trust it. LVM and such do make it more reliable, but I'd only do it in single user mode, so GUI is out anyway. Belt and braces, belt and braces (as far as futzing with disks on live systems is concerned anyway)...
I've always been more happy-go-lucky, which is probably why I lost my entire /home partition to an unfortunate ReiserFS resizing accident a few years back. The accident was to try and resize a ReiserFS partition. For the record, don't. :)
(I also once dd'ed a floppy disk image over the first 1.44MB of my root partition. /dev/sda and /dev/sdb are so *similar*, after all. Darn USB floppy drives. It's a good thing no-one's paying me to do quality assurance on the operating system they trust all their data to, really. That'd be a damn silly thing to do...)
On 11/02/2009 08:26 AM, Karel Volný wrote:
I'd suggest that anyone who sets up a system without any user accounts _and_ somehow needs a GUI to configure the system _and_ can't manage to figure out the settings to change so they can login as root should probably not be pretending to be a competent administrator.
I guess the last part is not correct - he *can* login as root, but *can not* run Konqueror as root ... that's a difference
oh, and also the original post was not about installing without ordinary user accounts
well, but this is not the point - the point is, that someone who supposes he's smarter than the others just disables a possibility for the others
please, stop protecting other people from themselves - if they want to risk being hurt, just let them get hurt ...
I've got a usecase - what about using Konqueror to configure CUPS
what is the security difference between doing $ su - # konqueror localhost:631
and
$ konqueror localhost:631
<supply root password to konqueror when asked for>
?
in the first case, if the attacker gets in control of Konqueror, he can do rm -rf / directly; in the latter, he can capture root password ... which may (or may not) be more valuable
Are there not enough examples from Windows of why it's a terrible idea to run with full administrator privileges -- especially software like web browsers?
I do not think that using Windows as an argument is worth here
and do not forget that Konqueror is also a file browser, not just web browser (oh, does everyone really has to do "cd /etc; vi someconfigfile" in the text console?)
K.
I went into root and deleted .kde and restarted and it fixed the problem of running Konqueror in root, But As far as user doing "kdesu konqueror" that still does not work. I have to do su - and then run konqueror from terminal and the it comes up.
Karel Voln wrote:
$ konqueror localhost:631
<supply root password to konqueror when asked for>
?
in the first case, if the attacker gets in control of Konqueror, he can do rm -rf / directly; in the latter, he can capture root password ... which may (or may not) be more valuable
I don't think much of your example, but in practice if some cracker tries to "rm -rf /" there's not a lot to choose, on my systems, between doing it as root and doing it is me. My valuables are mostly in ~ and the operating system is way easier to replace than the stuff in ~.
More likely, Ungodly will be looking for my banking details, and i I allow a browser to store unencrypted account details, being root doesn't make my situation worsse
However, I think the biggest hazards is through trojans, and if I can persuade you that you really should give my custom version of Firefox a burl, I've got you. along with Firefox I could install keyloggers to record what you type, I I can correlate what you type with where you go,,,,
Todd Zullinger wrote:
John Summerfield wrote:
Same with gnome. Someone's misguided attempt to secure the system. It's dead easy to install a system with no means to login to a GUI and configure stuff.
A note to the original poster, I misread your question, and interpreted it wrongly. Sorry about that.
All you need do is install sans user account.
I'd suggest that anyone who sets up a system without any user accounts _and_ somehow needs a GUI to configure the system _and_ can't manage to figure out the settings to change so they can login as root should probably not be pretending to be a competent administrator.
My security is my responsibility, not my vendor's. The vendor's responsibility is to provide tools and documentation.
Neither you nor my vendors understand my particular requirements and circumstances, and lacking that information you are poorly qualified to judge.
Here are the most relevant RHEL manuals: http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Installat... http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.4/html/Deploymen... Find where either one describes creating a user account during manua; (that is, not kickstart) installation.I looked, I don't see it and I don't recall it,
I've not done a manual install of Fedora for some time, my normal install for any of the RHL family is by kickstart, and I do normally create user accounts, add some to wheel and configure sudo so members of the wheel group can administer using sudo.
In contrast, Debian and Ubuntu insist.
Are there not enough examples from Windows of why it's a terrible idea to run with full administrator privileges -- especially software like web browsers?
Recommendations I've seen on windows are 1. Use administrative accounts for administration only. or 2. Use regular accounts, use "run as" to gain elevated privilege when required. Unfortunately for this advice, Windows Update failed for me on two systems, so I have it up. My approach is the first.
A well-designed GUI is not to be scorned. It presents the user's choices and provides guidance in making choices, and can make sure the choices are sane. Where a change must be reflected in several files, it can take care of that.
Of course, a TUI could do as well, but last I looked I could not find any TUI-writing tools to match what I had on MSDOS 3.31 (or OS/2 in DOS mode) last century.
It's dead easy to install a system with no means to login to a GUI and configure stuff.
Boot to runlevel 3 and log in as root, then create the account you want for graphical login ("useradd <worker-id>" and "passwd <worker-id>".
If things are so bad this does not work, boot to runlevel 1 and figure out what is wrong, or re-install.
On Sun, 2009-11-01 at 07:15 -0500, Richard Ryniker wrote:
It's dead easy to install a system with no means to login to a GUI and configure stuff.
Boot to runlevel 3 and log in as root, then create the account you want for graphical login ("useradd <worker-id>" and "passwd <worker-id>".
If things are so bad this does not work, boot to runlevel 1 and figure out what is wrong, or re-install.
Or hit Ctrl-Alt-F<n> and log in as root from a console.
poc
On 11/01/2009 07:18 AM, Patrick O'Callaghan wrote:
On Sun, 2009-11-01 at 07:15 -0500, Richard Ryniker wrote:
It's dead easy to install a system with no means to login to a GUI and configure stuff.
Boot to runlevel 3 and log in as root, then create the account you want for graphical login ("useradd<worker-id>" and "passwd<worker-id>".
If things are so bad this does not work, boot to runlevel 1 and figure out what is wrong, or re-install.
Or hit Ctrl-Alt-F<n> and log in as root from a console.
poc
I prefer Konqueror, I don't like using the Terminal when I'm showing a new user how to do something in Linux, it scares them off.
On Sun, 2009-11-01 at 09:53 -0500, Jim wrote:
On 11/01/2009 07:18 AM, Patrick O'Callaghan wrote:
On Sun, 2009-11-01 at 07:15 -0500, Richard Ryniker wrote:
It's dead easy to install a system with no means to login to a GUI and configure stuff.
Boot to runlevel 3 and log in as root, then create the account you want for graphical login ("useradd<worker-id>" and "passwd<worker-id>".
If things are so bad this does not work, boot to runlevel 1 and figure out what is wrong, or re-install.
Or hit Ctrl-Alt-F<n> and log in as root from a console.
poc
I prefer Konqueror, I don't like using the Terminal when I'm showing a new user how to do something in Linux, it scares them off.
If you re-read the thread, you'll see I wasn't addressing your original post but replying to John Summerfield's comment about not having any way of logging in as root when no user is configured.
poc
Richard Ryniker wrote:
It's dead easy to install a system with no means to login to a GUI and configure stuff.
Boot to runlevel 3 and log in as root, then create the account you want for graphical login ("useradd <worker-id>" and "passwd <worker-id>".
You seem to have missed the point. Nobody should have to work around this problem, it should not occur.
If Anaconda does not provide a means of creating an alternative _administrator_ account, then root needs to be able to login to use the preferred (by RH) GUI tools for creating user accounts
The current position is that root cannot login via the DM, but can do a text-mode login and then startx.
If things are so bad this does not work, boot to runlevel 1 and figure out what is wrong, or re-install.
Reinstalling wasn't going to fix the problem.
On 11/01/2009 01:05 AM, Rex Dieter wrote:
Jim wrote:
FC12/KDE
Were is Konqueror in Root ?
Konqueror can only be run as User.
kdesu konqueror
Or did you mean something else?
-- Rex
That is right Rex, but after you type in root password I still can't get Konqueror. Even if I login to Root There is still no Konqueror in root.
Jim wrote:
On 11/01/2009 01:05 AM, Rex Dieter wrote:
Jim wrote:
FC12/KDE
Were is Konqueror in Root ?
Konqueror can only be run as User.
kdesu konqueror
Or did you mean something else?
-- Rex
That is right Rex, but after you type in root password I still can't get Konqueror. Even if I login to Root There is still no Konqueror in root.
Wierd, works here. Maybe try clearing stuff in root's ~/.kde dir and/or /var/tmp/kdecache-root
-- Rex
-- Rex
Rex Dieter wrote:
Jim wrote:
On 11/01/2009 01:05 AM, Rex Dieter wrote:
Jim wrote:
FC12/KDE
Were is Konqueror in Root ?
Konqueror can only be run as User.
kdesu konqueror
Or did you mean something else?
-- Rex
That is right Rex, but after you type in root password I still can't get Konqueror. Even if I login to Root There is still no Konqueror in root.
Wierd, works here. Maybe try clearing stuff in root's ~/.kde dir and/or /var/tmp/kdecache-root
I just noticed an selinux denial when trying 'kdesu konqueror' on my f12 box, did you see anything selinux related?
-- Rex
On 11/01/2009 12:24 PM, Rex Dieter wrote:
Rex Dieter wrote:
Jim wrote:
On 11/01/2009 01:05 AM, Rex Dieter wrote:
Jim wrote:
FC12/KDE
Were is Konqueror in Root ?
Konqueror can only be run as User.
kdesu konqueror
Or did you mean something else?
-- Rex
That is right Rex, but after you type in root password I still can't get Konqueror. Even if I login to Root There is still no Konqueror in root.
Wierd, works here. Maybe try clearing stuff in root's ~/.kde dir and/or /var/tmp/kdecache-root
I just noticed an selinux denial when trying 'kdesu konqueror' on my f12 box, did you see anything selinux related?
-- Rex
Yes I did and it's not related to kdesu konqueror. But it comes up everytime I try to run kdesu konqueror.
Selinux is preventing the /usr/lib/cups/daemon/cups-driverd 'CLP-610-1200x600CMS2'
And that does not apply to kdesu konqueror at all, it has to do with my Samsung CLX3175FN print drivers.
I filed a Bug report on it.