This was a problem I had a while back. I lost the "Preferences" menu item in my "Applications" menu in Gnome. After much discussion, the following commands got my "Preferences" menu item back, along with all the applications inside of it:
rpm -e redhat-artwork redhat-menus --nodeps --allmatches yum install redhat-artwork redhat-menus
But...
For some reason it isn't working this time. My "Preferences" option in my application menu is gone, and I don't even know why it left. And doing the commands above aren't getting them back.
Actually, I have some suspicion as to why I've lost my "Preferences" option in my "Applications" menu. Last time this happened, it happened after I installed Amarok and ended up with a bunch of KDE settings I didn't want.
This time, I installed Quanta, which required some KDE libraries, but it didn't seem to cause as much chaos as last time.
However, the implications are that for some reason, having any KDE programs seems to affect my Gnome options.
What's up with that?
Dave
On Sun, 2005-10-02 at 21:42 +0900, Dave Gutteridge wrote:
This was a problem I had a while back. I lost the "Preferences" menu item in my "Applications" menu in Gnome. After much discussion, the following commands got my "Preferences" menu item back, along with all the applications inside of it:
rpm -e redhat-artwork redhat-menus --nodeps --allmatches yum install redhat-artwork redhat-menus
But...
For some reason it isn't working this time. My "Preferences" option in my application menu is gone, and I don't even know why it left. And doing the commands above aren't getting them back.
Actually, I have some suspicion as to why I've lost my "Preferences" option in my "Applications" menu. Last time this happened, it happened after I installed Amarok and ended up with a bunch of KDE settings I didn't want.
This time, I installed Quanta, which required some KDE libraries, but it didn't seem to cause as much chaos as last time.
However, the implications are that for some reason, having any KDE programs seems to affect my Gnome options.
What's up with that?
---- having KDE programs installed such as Quanta don't bother my system or my Gnome menus and I don't think your cause/effect analysis is accurate.
Suggest that you logout, grab a root shell, move your ~/.gnome2 to ~/.gnome2-bak and log back in. This should reset the gnome settings back to defaults but I am not knowledgeable about how/where things gnome are stored. You might want to move specific program settings back from the backup folder you created.
Craig
Suggest that you logout, grab a root shell, move your ~/.gnome2 to ~/.gnome2-bak and log back in. This should reset the gnome settings back to defaults but I am not knowledgeable about how/where things gnome are stored. You might want to move specific program settings back from the backup folder you created.
Unfortunately, that yielded no results.
I noticed when I logged into the root account, also in Gnome, and which should already be in default mode as I've never made any adjustments to it, is also missing the "Preferences" menu item in the Applications bar.
So it would seem it's not a matter of individual user settings, but something more general.
Dave
On Mon, 2005-10-03 at 20:53 +0900, Dave Gutteridge wrote:
Suggest that you logout, grab a root shell, move your ~/.gnome2 to ~/.gnome2-bak and log back in. This should reset the gnome settings back to defaults but I am not knowledgeable about how/where things gnome are stored. You might want to move specific program settings back from the backup folder you created.
Unfortunately, that yielded no results.
I noticed when I logged into the root account, also in Gnome, and which should already be in default mode as I've never made any adjustments to it, is also missing the "Preferences" menu item in the Applications bar.
So it would seem it's not a matter of individual user settings, but something more general.
--- indeed - it would seem that way.
You should never login to GUI as root. Never as in not ever.
If you want to test your theory as more general, create a new user and log in as that user (you can delete the user and his files/home directory easily, later).
If that new user doesn't have a Preferences Menu, then yes, I would agree that it is something more general that has impacted the menu structure.
Craig
You should never login to GUI as root. Never as in not ever.
Okay. Out of curiosity, why not?
If you want to test your theory as more general, create a new user and log in as that user (you can delete the user and his files/home directory easily, later).
I'd like to try this, but for some reason, I can't get a new user going. I create the user like this:
[root@localhost ~]# adduser -ppassword -m roger
But when I try to log in at the GUI prompt to get into Gnome, it always password incorrect. Am I creating the user wrong?
Dave
On Mon, 2005-10-03 at 23:00 +0900, Dave Gutteridge wrote:
You should never login to GUI as root. Never as in not ever.
Okay. Out of curiosity, why not?
---- long standing policy of least privileges necessary. KDE wouldn't allow it at all. Way too much software inadequately audited for security issues and you could clobber anything. ----
If you want to test your theory as more general, create a new user and log in as that user (you can delete the user and his files/home directory easily, later).
I'd like to try this, but for some reason, I can't get a new user going. I create the user like this:
[root@localhost ~]# adduser -ppassword -m roger
But when I try to log in at the GUI prompt to get into Gnome, it always password incorrect. Am I creating the user wrong?
---- useradd -p PASSWORD -m roger ^ needs a ^ space | | what are you trying to accomplish here?
Craig
useradd -p PASSWORD -m roger ^ needs a ^ space | | what are you trying to accomplish here?
The web page where I got the command said I needed it. Said it was to create a home directory.
In any case, I tried: useradd -p password testguy
and I still can't log in at the GUI prompt with the username "testguy" and the password "password".
Do I have to specify to set up a Gnome interface for the user or something like that?
Dave
On Mon, 2005-10-03 at 23:41 +0900, Dave Gutteridge wrote:
useradd -p PASSWORD -m roger ^ needs a ^ space | | what are you trying to accomplish here?
The web page where I got the command said I needed it. Said it was to create a home directory.
In any case, I tried: useradd -p password testguy
and I still can't log in at the GUI prompt with the username "testguy" and the password "password".
Do I have to specify to set up a Gnome interface for the user or something like that?
---- I just do
useradd testguy -g dom_users # primary group passwd testguy
and have no problems - but that is a two step process.
I was worried about the '-m' option to use an already screwed up profile as a template which would continue the issue.
Craig
Okay, I finally figured out what the problem was in making a new user. Turns out that I can only log in with the newly created user account after having rebooted. I would have thought it would have been good enough to just log out and log back in, but apparently not.
Anyway, now I can get back on track to the original point of this thread.
I logged into the new account and the missing "Preferences" menu item was not there either. So whatever has changed to remove it from my menu has happened globally to all users.
So if it's not just a user settings issue, then what could it be?
Dave
On 04/10/05, Dave Gutteridge dave@tokyocomedy.com wrote:
I logged into the new account and the missing "Preferences" menu item was not there either. So whatever has changed to remove it from my menu has happened globally to all users.
So if it's not just a user settings issue, then what could it be?
Has anything been updated recently? Are any KDE packages listed near the end out of...
rpm -qa --last | tac
Will.
Has anything been updated recently? Are any KDE packages listed
Oh, yeah. Lots of stuff. In fact, I started out this thread by pointing out that I had installed Quanta, which required me to install a whole shebang of KDE libraries.
But I was told that nothing I did with KDE should impact what I have in Gnome. Which sounds reasonable, but I have to admit that it still seems suspicious to me that this problem has happened twice, both times after installing KDE related libraries.
Anyway, to answer your question directly, here are the KDE related packages that result from the command you suggest:
openslp-1.2.1-0.2.el4.rf Fri 23 Sep 2005 02:20:13 AM JST kdelibs-3.4.2-1.2.el4.kde Fri 23 Sep 2005 02:34:14 AM JST kdewebdev-3.4.2-1.0.el4.kde Fri 23 Sep 2005 02:35:14 AM JST libtidy-0.99.0-2.20041214 Fri 23 Sep 2005 02:39:14 AM JST tidy-0.99.0-2.20041214 Fri 23 Sep 2005 02:39:34 AM JST mozilla-nspr-1.7.12-1.4.1.centos4 Sat 24 Sep 2005 01:04:00 AM JST mozilla-nss-1.7.12-1.4.1.centos4 Sat 24 Sep 2005 01:04:17 AM JST firefox-1.0.7-1.4.1.centos4 Sat 24 Sep 2005 01:04:27 AM JST taglib-1.4-1.el4 Sat 24 Sep 2005 12:25:14 PM JST k3b-0.12.3-1.1.el4.kde Sat 24 Sep 2005 12:25:18 PM JST libofx-0.7.0-0.0.el4.kde Sat 24 Sep 2005 12:25:24 PM JST gift-openft-0.2.1.6-0.lvn.1.el4 Sat 24 Sep 2005 12:25:25 PM JST scim-libs-1.4.2-3.el4.kb Tue 27 Sep 2005 12:13:17 AM JST qt-3.3.4-17.4.el4.kde Tue 27 Sep 2005 12:13:19 AM JST boost-1.33.0-0.3.el4 Tue 27 Sep 2005 12:13:36 AM JST scim-1.4.2-3.el4.kb Tue 27 Sep 2005 12:14:57 AM JST boost-devel-1.33.0-0.3.el4 Tue 27 Sep 2005 12:15:12 AM JST qt-devel-3.3.4-17.4.el4.kde Tue 27 Sep 2005 12:15:49 AM JST cups-libs-1.1.22-0.rc1.9.8 Wed 28 Sep 2005 09:22:30 AM JST cups-1.1.22-0.rc1.9.8 Wed 28 Sep 2005 09:24:25 AM JST wget-1.10.1-2.4E.1 Wed 28 Sep 2005 09:24:59 AM JST redhat-artwork-0.124-1.0.el4.kde Sun 02 Oct 2005 01:17:37 PM JST redhat-menus-3.8-0.1.3.kde
Dave
On 04/10/05, Dave Gutteridge dave@tokyocomedy.com wrote:
Has anything been updated recently? Are any KDE packages listed
Oh, yeah. Lots of stuff. In fact, I started out this thread by pointing out that I had installed Quanta, which required me to install a whole shebang of KDE libraries.
Oops, I wasn't paying too much attention initially, I don't tend to bother trying to help with GUI stuff as I don't do much of it. :)
But I was told that nothing I did with KDE should impact what I have in Gnome. Which sounds reasonable, but I have to admit that it still seems suspicious to me that this problem has happened twice, both times after installing KDE related libraries.
Anyway, to answer your question directly, here are the KDE related packages that result from the command you suggest:
redhat-menus-3.8-0.1.3.kde
Well the redhat-menus provide defaults for both KDE and Gnome, presumably as part of the unified Bluecurve look and feel?
This is from WBEL but should be applicable to CentOS too...
[root@willspc etc]# rpm -qil system-menus-3.7.1-2.WB1 Name : system-menus Relocations: (not relocatable) Version : 3.7.1 Vendor: whiteboxlinux.org Release : 2.WB1 Build Date: Fri 29 Apr 2005 08:37:18 BST Install Date: Tue 31 May 2005 11:16:25 BST Build Host: bob.whiteboxlinux.org Group : User Interface/Desktops Source RPM: system-menus-3.7.1-2.WB1.src.rpm Size : 580236 License: XFree86 Signature : DSA/SHA1, Wed 04 May 2005 02:47:31 BST, Key ID ae52a76d73307de6 URL : http://www.redhat.com Summary : Configuration and data files for the desktop menus Description :
This package contains the XML files that describe the menu layout for GNOME and KDE, and the .desktop files that define the names and icons of "subdirectories" in the menus. /etc/X11/starthere /etc/X11/starthere/applications.desktop /etc/X11/starthere/preferences.desktop /etc/X11/starthere/sysconfig.desktop /etc/xdg /etc/xdg/menus /etc/xdg/menus/applications.menu /etc/xdg/menus/preferences.menu /etc/xdg/menus/server-settings.menu /etc/xdg/menus/start-here.menu /etc/xdg/menus/system-settings.menu
Are both /etc/X11/starthere/preferences.desktop and /etc/xdg/menus/preferences.menu present? I wonder if one of those packages has modified them and the reinstall is just creating .rpmnew files rather than replacing the defaults you want?
Is there anything suspicious in your ~/Desktop/ (check for .dot files too).
Well the redhat-menus provide defaults for both KDE and Gnome, presumably as part of the unified Bluecurve look and feel?
So there is some connection, then?
Are both /etc/X11/starthere/preferences.desktop and /etc/xdg/menus/preferences.menu present?
Both present. I opened them in a text editor, but was unable to discern anything useful about them with my newbie eyes.
I wonder if one of those packages has modified them and the reinstall is just creating .rpmnew files rather than replacing the defaults you want?
That sounds like a good theory. If they were modified, I can't tell how. Any way I could test this theory?
Is there anything suspicious in your ~/Desktop/ (check for .dot files too).
No hidden files, and nothing that I can identify as odd. Seems to me that everything in my Desktop directory are documents and video files that I'm currently working on, nothing to do with system settings.
As ever, I should qualify all of my observations with the fact that, as a newbie, I may have missed the obvious.
Dave
Dave Gutteridge wrote:
Okay, I finally figured out what the problem was in making a new user. Turns out that I can only log in with the newly created user account after having rebooted. I would have thought it would have been good enough to just log out and log back in, but apparently not.
[snip]
I don't understand why you should even need to log out (except that you need to use the same keyboard, something like that, but no *system* reason).
Certainly on my system I've created a new user, and immediately had the new user log in.
Mike
I don't understand why you should even need to log out (except that you need to use the same keyboard, something like that, but no *system* reason).
Beats me. I think it's weird too. But, honestly, I'm not so worried about it. I'm much more interested in trying to get my default menu options back. After it was determined that it wasn't just a user settings issue, advice about what to do sort of dropped off and I'm unsure about what to do.
Dave
On Fri, 2005-10-07 at 20:17 +0900, Dave Gutteridge wrote:
I don't understand why you should even need to log out (except that you need to use the same keyboard, something like that, but no *system* reason).
Beats me. I think it's weird too. But, honestly, I'm not so worried about it. I'm much more interested in trying to get my default menu options back. After it was determined that it wasn't just a user settings issue, advice about what to do sort of dropped off and I'm unsure about what to do.
What seems to have happened is that you have updated your RPMS for all of KDE again to a new version. Part of that upgrade was an upgrade to the package redhat-menus-3.7.1-2.noarch.rpm ... once you upgraded that package to a new one, your default menus would have changed.
I am not even sure if the older (original) redhat-menus will work with the new KDE.
I have tried to convey in the past the need to NOT use non CentOS repos ... or to greatly restrict what these repos can update on a CentOS machine (if one wants to keep their machine CentOS and not Fedora Core or Rawhide).
I have tried to convey in the past the need to NOT use non CentOS repos ... or to greatly restrict what these repos can update on a CentOS machine
I'm on board with that. But when I wanted to install Quanta, I was given advice on this list that the KDE repos necessary to get it were safe.
I'm not pointing fingers, just saying that I'm in a bit of a swirling vortex of advice, and it doesn't always line up. And I don't have the skills to to discern which side of advice that conflicts that I should follow.
If I want to install something like Quanta, or any other software that isn't in Dag or the official CentOS repos, then I might as well just consider it not available?
Dave
On Fri, 2005-10-07 at 21:03 +0900, Dave Gutteridge wrote:
I have tried to convey in the past the need to NOT use non CentOS repos ... or to greatly restrict what these repos can update on a CentOS machine
I'm on board with that. But when I wanted to install Quanta, I was given advice on this list that the KDE repos necessary to get it were safe.
I'm not pointing fingers, just saying that I'm in a bit of a swirling vortex of advice, and it doesn't always line up. And I don't have the skills to to discern which side of advice that conflicts that I should follow.
If I want to install something like Quanta, or any other software that isn't in Dag or the official CentOS repos, then I might as well just consider it not available?
---- not necessarily - it's the repo's that you are using with yum that could be at issue...
what's output of
cat /etc/yum.conf
cat /etc/yum.repos.d/*
Apparently you still have the kde repo configured
Craig
Dave Gutteridge wrote:
I have tried to convey in the past the need to NOT use non CentOS repos ... or to greatly restrict what these repos can update on a CentOS machine
I'm on board with that. But when I wanted to install Quanta, I was given advice on this list that the KDE repos necessary to get it were safe.
FYI, you used the kde-redhat repo to get it. kde-redhat simply syncs with the latest redhat-menus (which is at version 3.8 from Fedora Core 4). Apparently, redhat-menus-3.8 varies a bit from 3.7.1 (I personally hadn't noticed much/any difference).
-- Rex
On Fri, 2005-10-07 at 21:03 +0900, Dave Gutteridge wrote:
I'm on board with that. But when I wanted to install Quanta, I was given advice on this list that the KDE repos necessary to get it were safe.
Opinions and quality of advice will vary. [I remember causing you to corrupt a M$ vfat disk by not giving enough warnings on fstab flags that caused alfa dosfsck to run.] Advice on KDE repos seems, at best, mixed - seems to work well for some, but other knowledgeable people strongly advise against it.
I'm not pointing fingers, just saying that I'm in a bit of a swirling vortex of advice, and it doesn't always line up. And I don't have the skills to to discern which side of advice that conflicts that I should follow.
<sarcasm> So what else is new? :-) </sarcasm>
If anyone has a good answer for this problem, I'm sure the whole open- source community would like to hear it. Often it's going to be cut-and- try even for the most knowledgeable.
If I want to install something like Quanta, or any other software that isn't in Dag or the official CentOS repos, then I might as well just consider it not available?
If I can't find things I want/need in EL4 repos (or in general distro- specific repos), I try to find *.src.rpm, rebuild, and populate my local repos. If this fails, I sometimes "cherry-pick" other repos for binary rpms, or [as a last resort] source tarballs, but enabling non-EL- compatible repos is to be avoided IMHO.
Which EL4 repos to use is also, unfortunately, more of an art than a science. I find kbs, dag, and dries generally play well together and with the core repos, but atrpms is much trickier, even for EL4 packages - I just cherry-pick that one, usually with Smart to help.
Probably not very helpful, by my $0.02.
Phil
Johnny Hughes wrote:
What seems to have happened is that you have updated your RPMS for all of KDE again to a new version. Part of that upgrade was an upgrade to the package redhat-menus-3.7.1-2.noarch.rpm ... once you upgraded that package to a new one, your default menus would have changed.
Bingo. I've pointed that out in this thread too. I guess Dave missed it.
I am not even sure if the older (original) redhat-menus will work with the new KDE.
It'll be fine.
-- Rex
Bingo. I've pointed that out in this thread too. I guess Dave missed it.
Not so much missed it as didn't understand it. I mean, where do I get Quanta from if not the kde-redhat menu?
Or, how do I get my previous menu without losing Quanta?
I must be missing something because it seems like it's one or the other.
Dave
Dave Gutteridge wrote:
Bingo. I've pointed that out in this thread too. I guess Dave missed it.
Not so much missed it as didn't understand it. I mean, where do I get Quanta from if not the kde-redhat menu?
^^^^^^^^^^^^^^^ I assume you meant kde-redhat repo. I know of no other repo providing quanta.
Or, how do I get my previous menu without losing Quanta?
Downgrade to CentOS's stock redhat-menus rpm.
(assuming you have the rpm handy, and/or have downloaded it already): rpm -Uvh --oldpackage redhat-menus-3.7.1-2.noarch.rpm
-- Rex
On Fri, 2005-10-07 at 08:13 -0500, Rex Dieter wrote:
Dave Gutteridge wrote:
Bingo. I've pointed that out in this thread too. I guess Dave missed it.
Not so much missed it as didn't understand it. I mean, where do I get Quanta from if not the kde-redhat menu?
^^^^^^^^^^^^^^^I assume you meant kde-redhat repo. I know of no other repo providing quanta.
Or, how do I get my previous menu without losing Quanta?
Downgrade to CentOS's stock redhat-menus rpm.
(assuming you have the rpm handy, and/or have downloaded it already): rpm -Uvh --oldpackage redhat-menus-3.7.1-2.noarch.rpm
---- but if he has kde-redhat repo configured in yum.repos.d, then he has the 'opportunity' to relive this experience time and again. He really needs to disable or remove the repo from his configuration as it appears evident that the dirty work is somewhat automatic.
Craig
(assuming you have the rpm handy, and/or have downloaded it already): rpm -Uvh --oldpackage redhat-menus-3.7.1-2.noarch.rpm
This, combined with removing the KDE repos from my YUM configuration, turned out to be the winning solution.
Thanks to all who provided advice and insight.
Dave
On Monday 03 October 2005 09:00 am, Dave Gutteridge wrote:
You should never login to GUI as root. Never as in not ever.
Okay. Out of curiosity, why not?
Two Schools of thought:
#1 By logging in to do a few tasks as root, you open numerous programs as root you do not need to. This creates a security problem - programs running with root privileges for no reason.
#2 Windows admins log in as administrator all the time, and somehow keep their machines malware free (well, some do), and certain types of network equipment has a gui - and no user OTHER than root or admin!
I've always thought its best to use your judgment. Small tasks - use the commandline, without a doubt. If you have 80 things to do, unjack from the network and login as root. If the machine is running in production and you are afraid of the consequences....wait, why do you need to change 80 things on a production machine?? :-P
Some modern versions of Debian will *not* let you login as root at the login screen, or run a program as root easily (have to use the kdesu or sudo facilities). I think this is overkill. Some level of judgement should be allowed on the part of the operator.
On Mon, 2005-10-03 at 17:53 -0500, Ryan wrote:
On Monday 03 October 2005 09:00 am, Dave Gutteridge wrote:
You should never login to GUI as root. Never as in not ever.
Okay. Out of curiosity, why not?
Two Schools of thought:
#1 By logging in to do a few tasks as root, you open numerous programs as root you do not need to. This creates a security problem - programs running with root privileges for no reason.
#2 Windows admins log in as administrator all the time, and somehow keep their machines malware free (well, some do), and certain types of network equipment has a gui - and no user OTHER than root or admin!
---- What Windows does has nothing to do with Unix/Linux. If you have Win2K3 server with latest service packs, it's virtually impossible to use Internet Explorer now without indicating to Internet Explorer that you wish to downgrade security. As for keeping it free of malware, not if you actually use the machine as administrator for anything beyond administration.
Heck - Microsoft recommends that you not have administrative privileges on your own Windows XP desktop. They just keep it quiet and by default, give you administrative privileges on setup. ----
I've always thought its best to use your judgment. Small tasks - use the commandline, without a doubt. If you have 80 things to do, unjack from the network and login as root. If the machine is running in production and you are afraid of the consequences....wait, why do you need to change 80 things on a production machine?? :-P
Some modern versions of Debian will *not* let you login as root at the login screen, or run a program as root easily (have to use the kdesu or sudo facilities). I think this is overkill. Some level of judgement should be allowed on the part of the operator.
---- It's really a much better concept. I think it's only because RedHat by default uses GDM that you can login as root on runlevel 5. It's really a poor idea. Debian (and things like Ubuntu) have it right.
Craig
On Monday 03 October 2005 05:02 pm, Craig White wrote:
What Windows does has nothing to do with Unix/Linux.
Ok, but a fair comparison is a Windows admin who logs on as 'administrator' and a Linux admin who logs on as 'root'.
While the two OS's are very different, the end result of logging on as root is very similar.
Debian (and things like Ubuntu) have it right.
I disagree entirely. So long as the user is displayed a warning indicating that its a bad idea to do so, I see nothing wrong with allowing a user to control their own system.
It's really a poor idea.
Ok, I have to ask. If I log in to machine *not connected to any network*, and I am doing admin tasks, what danger do I run that I wouldn't if I run as root from a terminal on a limited account?
The Debian distros (Ubuntu, Mepis) sudo setup is way more complicated than necessary - it offers no more protection with significantly more headaches. Nothing is as pointless as forcing a user to use sudo to run a compiler.
If I want an "admin" account and a "root" account I'll go burn my money on a mac. :-)
On Mon, 2005-10-03 at 21:26 -0500, Ryan wrote:
On Monday 03 October 2005 05:02 pm, Craig White wrote:
What Windows does has nothing to do with Unix/Linux.
Ok, but a fair comparison is a Windows admin who logs on as 'administrator' and a Linux admin who logs on as 'root'.
While the two OS's are very different, the end result of logging on as root is very similar.
---- If you merely call root on Linux, Administrator on Windows both 'superusers' the identification is much the same. The difference is, any Linux distribution worth it's salt will give you methods to access superuser privileges from a normal login whereas you have to have Administrator privileges to do superuser tasks on Windows. There is a big distinction. If you need to download say a print driver, you are using a web browser as a normal user in Linux and as superuser in Windows. ----
Debian (and things like Ubuntu) have it right.
I disagree entirely. So long as the user is displayed a warning indicating that its a bad idea to do so, I see nothing wrong with allowing a user to control their own system.
---- OK - it's your machine, your call ----
It's really a poor idea.
Ok, I have to ask. If I log in to machine *not connected to any network*, and I am doing admin tasks, what danger do I run that I wouldn't if I run as root from a terminal on a limited account?
---- you may have already downloaded some malicious code in a web browser plugin, java applet or ??? that doesn't get executed until you fire up the root account and use a web browser. Just the first idea that comes to my mind...I'm not gonna spend a lot of time thinking about the what ifs. ----
The Debian distros (Ubuntu, Mepis) sudo setup is way more complicated than necessary - it offers no more protection with significantly more headaches. Nothing is as pointless as forcing a user to use sudo to run a compiler.
If I want an "admin" account and a "root" account I'll go burn my money on a mac. :-)
---- Mac's are as bad as Windows - making everyone a superuser by default. These guys aren't at all concerned with security - only ease of use. Don't get me started on OSX - it's OT on this list anyway.
Craig
On Monday 03 October 2005 09:48 pm, you wrote:
Debian (and things like Ubuntu) have it right.
I disagree entirely. So long as the user is displayed a warning indicating that its a bad idea to do so, I see nothing wrong with allowing a user to control their own system.
OK - it's your machine, your call
Allowing a user to shoot themselves in the foot is required if you assume that the user base is knowledgeable enough to use their power wisely.
I think the concept is a lot like using weak passwords. They *should* be permitted - and in some cases (for example - a headless machine with only SSH access that is using host-key authentication) it might not even be a security risk. The user should receive a very stern warning/disclaimer about their actions before being allowed to set the simple password though.
you may have already downloaded some malicious code in a web browser plugin, java applet or ??? that doesn't get executed until you fire up the root account and use a web browser. Just the first idea that comes to my mind...I'm not gonna spend a lot of time thinking about the what ifs.
Ok.
In the case you present, the malicious code wouldn't run as it wouldn't have been downloaded into the root account's profile for firefox or KDE.
Also, this same risk (if it is a risk at all) is present if I need to start firefox as root from the commandline to add some search engines to the search bar (this is a root-only task).
Dave Gutteridge wrote:
This was a problem I had a while back. I lost the "Preferences" menu item in my "Applications" menu in Gnome. After much discussion, the following commands got my "Preferences" menu item back, along with all the applications inside of it:
rpm -e redhat-artwork redhat-menus --nodeps --allmatches
Right.
yum install redhat-artwork redhat-menus
You may want/need to downgrade to the stock redhat-menus-3.7.1, instead of using the newer redhat-menus-3.8 provided by kde-redhat.
-- Rex
-
Craig White -
Dave Gutteridge -
Johnny Hughes -
Mike McCarty -
Phil Schaffner -
Rex Dieter -
Ryan -
Will McDonald