Fedora Linux Support Community & Resources Center
  #1  
Old 12th March 2011, 12:49 PM
Shugs81 Offline
Registered User
 
Join Date: Mar 2010
Posts: 154
linuxfedorafirefox
Gedit not working for root

Hi,

When trying to use gedit in su mode get this:
Code:
(gedit:2340): EggSMClient-WARNING **: Failed to connect to the session manager: None of the authentication protocols specified are supported

**
GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL)
Aborted (core dumped)
although it works ok under normal account....

tried removing and reinstalling but no change

any other options or a way to boot the graphic mode in root?

Ta peeps!
Reply With Quote
  #2  
Old 12th March 2011, 12:53 PM
glennzo Online
Un-Retired Administrator
 
Join Date: Mar 2004
Location: Salem, Mass USA
Age: 57
Posts: 14,699
linuxchrome
Re: Gedit not working for root

Try using su - instead of just su.
__________________
Glenn
The Bassinator © ®

[SIGPIC][/SIGPIC]
Laptop: Toshiba Satellite / Intel Core 2 Duo 1.73 GHz / 2GB / 160GB / Intel Mobile 945GM/GMS/GME/943/940GML Integrated Graphics
Desktop: BioStar MCP6PB M2+ / AMD Phenom 9750 Quad Core / 4GB / 1TB SATA / 500GB SATA / EVGA GeForce 8400 GS 1GB
Reply With Quote
  #3  
Old 12th March 2011, 03:08 PM
motnahp00
Guest
 
Posts: n/a
windows_7firefox
Re: Gedit not working for root

glennzo's suggestion works but I am curious as to why su doesn't use the current environment to run gedit.
Reply With Quote
  #4  
Old 12th March 2011, 03:19 PM
glennzo Online
Un-Retired Administrator
 
Join Date: Mar 2004
Location: Salem, Mass USA
Age: 57
Posts: 14,699
linuxfedorafirefox
Re: Gedit not working for root

I've seen an explanation recently. Google for it. (Not being a wise guy, I don't know the answer).

I believe that it has to do with the fact that su - loads root's environment and su doesn't, but Google it anyhow.
__________________
Glenn
The Bassinator © ®

[SIGPIC][/SIGPIC]
Laptop: Toshiba Satellite / Intel Core 2 Duo 1.73 GHz / 2GB / 160GB / Intel Mobile 945GM/GMS/GME/943/940GML Integrated Graphics
Desktop: BioStar MCP6PB M2+ / AMD Phenom 9750 Quad Core / 4GB / 1TB SATA / 500GB SATA / EVGA GeForce 8400 GS 1GB
Reply With Quote
  #5  
Old 12th March 2011, 03:21 PM
jpollard Online
Registered User
 
Join Date: Aug 2009
Location: Waldorf, Maryland
Posts: 6,830
linuxfedorafirefox
Re: Gedit not working for root

Quote:
Originally Posted by motnahp00 View Post
glennzo's suggestion works but I am curious as to why su doesn't use the current environment to run gedit.
Because root is not authorized to access all elements of that environment - it is not root, it is the user, and the users environment has unverified data within it that may cause a system compromise.
Reply With Quote
  #6  
Old 12th March 2011, 05:34 PM
motnahp00
Guest
 
Posts: n/a
windows_7ie
Re: Gedit not working for root

If you provided root credentials and have control over the entire system, why wouldn't you be able to run an application in the user's local environment?

I think there is a mismatch for the gedit path. I am able to run other applications like vi and clock elevating into just su.

---------- Post added at 11:24 AM ---------- Previous post was at 11:23 AM ----------

Quote:
Originally Posted by glennzo View Post
I've seen an explanation recently. Google for it. (Not being a wise guy, I don't know the answer).

I believe that it has to do with the fact that su - loads root's environment and su doesn't, but Google it anyhow.
No harm taken glennzo. Googling right now.

---------- Post added at 11:34 AM ---------- Previous post was at 11:24 AM ----------

glennzo: In a debian form, I found a similiar thread regarding this topic. One response was to use su -l.

My friend info su shows the following:

'-'
'-l'
'--login'

No difference between using su - and su -l.
Reply With Quote
  #7  
Old 13th March 2011, 03:17 AM
Shugs81 Offline
Registered User
 
Join Date: Mar 2010
Posts: 154
linuxfedorafirefox
Re: Gedit not working for root

cheers peeps... will give that a shot!
Reply With Quote
  #8  
Old 13th March 2011, 07:16 PM
zyxon Offline
Registered User
 
Join Date: Apr 2010
Location: Hungary
Age: 23
Posts: 6
linuxchrome
Re: Gedit not working for root

for running GUI apps as root I'd do beesu foo (or gksu foo)
install it with:

Code:
su 
yum install beesu
__________________
Registered Linux user number: #506129
Reply With Quote
  #9  
Old 13th March 2011, 11:47 PM
Shugs81 Offline
Registered User
 
Join Date: Mar 2010
Posts: 154
windows_7firefox
Re: Gedit not working for root

well gedit used to run gui with su before but it didn't.... will try the '-' and see how it goes and if not will try beesu...
Reply With Quote
  #10  
Old 13th March 2011, 11:56 PM
buckyb Offline
Registered User
 
Join Date: Mar 2011
Posts: 28
linuxchrome
Re: Gedit not working for root

Quote:
Originally Posted by Shugs81 View Post
well gedit used to run gui with su before but it didn't.... will try the '-' and see how it goes and if not will try beesu...
My way might be redundant, but since it works, I'm sure there is a good technical explanation.

1. "su" (to get in as root)
2. sudo gedit .......................

For some reason, even as root, I still have to type "sudo" for gedit.

Last edited by buckyb; 14th March 2011 at 12:03 AM.
Reply With Quote
  #11  
Old 14th March 2011, 12:09 AM
glennzo Online
Un-Retired Administrator
 
Join Date: Mar 2004
Location: Salem, Mass USA
Age: 57
Posts: 14,699
linuxfirefox
Re: Gedit not working for root

On my laptop running F15 Alpha.
Quote:
[glenn@15alpha ~]$ su
Password:
[root@15alpha glenn]# gedit
Gtk-Message: Failed to load module "pk-gtk-module"

(gedit:4825): EggSMClient-WARNING **: Failed to connect to the session manager: None of the authentication protocols specified are supported

g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
Terminated
[root@15alpha glenn]# exit
exit
[glenn@15alpha ~]$ su -
Password:
[root@15alpha ~]# gedit
Gtk-Message: Failed to load module "pk-gtk-module"
At this point gedit opened as expected. The following errors occurred when I closed gedit.

(gedit:4850): Gtk-WARNING **: Attempting to store changes into `/root/.local/share/recently-used.xbel', but failed: Failed to create file '/root/.local/share/recently-used.xbel.M4FESV': No such file or directory

(gedit:4850): Gtk-WARNING **: Attempting to set the permissions of `/root/.local/share/recently-used.xbel', but failed: No such file or directory
__________________
Glenn
The Bassinator © ®

[SIGPIC][/SIGPIC]
Laptop: Toshiba Satellite / Intel Core 2 Duo 1.73 GHz / 2GB / 160GB / Intel Mobile 945GM/GMS/GME/943/940GML Integrated Graphics
Desktop: BioStar MCP6PB M2+ / AMD Phenom 9750 Quad Core / 4GB / 1TB SATA / 500GB SATA / EVGA GeForce 8400 GS 1GB
Reply With Quote
  #12  
Old 14th March 2011, 12:44 AM
jpollard Online
Registered User
 
Join Date: Aug 2009
Location: Waldorf, Maryland
Posts: 6,830
linuxfedorafirefox
Re: Gedit not working for root

I think you should also have gotten a SELinux alert.

the security model used has been tweaked, exactly how I don't know.

I think it is trying to use a users authentication identity for root access, which isn't allowed.

I believe the final reason is the not what is being accessed, but how it is being accessed - and that has changed.

A "su -" command alters the user process such that the real uid and effective uid are the same (root). A "su" command
alters the user process such that the real uid remain the users id, and the effective uid is root. The error/warning is caused by a change in the kernel of how valid tests are done. Previously, only the effective UID was matched against file access, and I believe that most of the time that is still true...
But now the tests (at least for root) are requiring both real and effective to match when modifying some data structures (in this case, session save support) because this COULD allow an information leak from root to an uncontrolled user environment (aka, a "covert channel").

Covert channels are notoriously hard to close. They allow a way for sensitive information (as in the possiblity of using gedit to modify the /etc/shadow file)
to leak encrypted passwords into a session save data file, used to restart an edit. Such session restart data may not be as secured as the information should be (in this example, the encrypted passwords), and is possible for the file to be group readable, even if unintentional.

I have NOT done a code level investigation as the gnome runtime has a LOT of code... and tracing this particular error backwards through the runtime library, into the gedit application is not something I would do willingly. It is very possible this problem has existed for some time, and only recently been closed.

Last edited by jpollard; 14th March 2011 at 02:12 AM. Reason: A slightly different explaination after some research
Reply With Quote
  #13  
Old 14th March 2011, 05:49 AM
flyingfsck Online
Registered User
 
Join Date: Aug 2010
Location: Al Ain, UAE
Posts: 1,845
linuxfedorafirefox
Re: Gedit not working for root

Quote:
My way might be redundant, but since it works, I'm sure there is a good technical explanation.
As someone else said, but to make it clear: su SPACE DASH

written as:
$ su -
password
# gedit /etc/fstab

That works.

Cheers,

F.
Reply With Quote
  #14  
Old 14th March 2011, 07:37 AM
buckyb Offline
Registered User
 
Join Date: Mar 2011
Posts: 28
linuxchrome
Re: Gedit not working for root

Quote:
Originally Posted by flyingfsck View Post
As someone else said, but to make it clear: su SPACE DASH

written as:
$ su -
password
# gedit /etc/fstab

That works.

Cheers,

F.
From what I understand,

su: gives you root privileges but not root environment, which is required if you want certain paths ..

su space dash : gives you root privileges and root environment, since using "-", is way of not specifying a user, so the shell defaults to the root user.

Is this correct?

I found a good explanation, I'm going to post it down below:

Quote:
Changing the Home Directory and Environmental Variables

The default behavior of su is to maintain the current directory and the environmental variables of the original user (rather than switch to those of the new user). Although the shell account likewise remains that of the original user, any new, unprivileged user (i.e., users other than root and others with some system privileges) does not gain automatic access to the directories or files of the former owner of the session.

Environmental variables are a class of variables that tell the shell how to behave as a user works at the command line (i.e., all-text mode) or in shell scripts (i.e., programs written in shell programming languages). They can be, and often are, set differently for each user.

The single most important environmental variable is PATH. When a user types in a command at the command line, the shell searches through all directories listed in PATH until it finds a program with that name. It is important to keep in mind the fact that there are different PATH settings for ordinary users and root.

The contents of the PATH file for the owner of the current session can be seen by issuing the following command:

echo $PATH

For ordinary users PATH is usually something like /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/username/bin: For root it generally resembles /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin.

Thus, if there is an executable (i.e., a runnable program) in the directory /usr/local/bin, root will have to supply the full path in order to run that application, otherwise the shell will just return the error message command not found. The full path is the name of the command or program preceded by its path from the root directory (which is represented by a forward slash and which should not be confused with /root, the root user's home directory). An ordinary user would only need to type the name of the command or program in such case, and not its full path, because /user/local/bin is in the user's PATH.

It sometimes can be advantageous for a system administrator to use the shell account of an ordinary user rather than its own. In particular, occasionally the most efficient way to solve a user's problem is to log into that user's account in order to reproduce or debug the problem.

However, in many situations it is not desirable, or it can even be dangerous, for the root user to be operating from an ordinary user's shell account and with that account's environmental variables rather than from its own. While inadvertently using an ordinary user's shell account, root could install a program or make other changes to the system that would not have the same result as if they were made while using the root account. For instance, a program could be installed that could give the ordinary user power to accidentally damage the system or gain unauthorized access to certain data.

Thus, it is advisable that administrative users, as well as any other users that are authorized to use su (of which there should be very few, if any), acquire the habit of always following the su command with a space and then a hyphen. The hyphen has two effects: (1) it switches the current directory to the home directory of the new user (e.g., to /root in the case of the root user) and (2) it changes the environmental variables to those of the new user. That is, if the first argument to su is a hyphen, the current directory and environment will be changed to what would be expected if the new user had actually logged on to a new session (rather than just taking over an existing session).

Thus, administrators should generally use su as follows:

su -

An identical result is produced by adding the username root, i.e.,

su - root

Likewise, the same can be done for any other user, e.g., for a user named bob:

su - bob

An argument, also called a command line argument, is a file or other information that is provided to a command in order for that command to use it as an input. Arguments used with su can include the hyphen and a username as well as arguments for commands that are used with su.
http://www.linfo.org/su.html

Last edited by buckyb; 14th March 2011 at 07:42 AM.
Reply With Quote
  #15  
Old 18th March 2011, 12:18 PM
Shugs81 Offline
Registered User
 
Join Date: Mar 2010
Posts: 154
linuxfedorafirefox
Re: Gedit not working for root

<code>su -</code>
Worked fine.... just hope i've done my fstab right!!! lol
Reply With Quote
Reply

Tags
gedit, root, working

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
F14, can't run gedit as root twohot Using Fedora 44 29th November 2011 06:41 AM
[SOLVED] Gedit Root Error dmachop Using Fedora 2 1st January 2011 02:34 PM
[SOLVED] gedit can't change font size as root errorxp Using Fedora 2 27th August 2010 11:25 AM
Can't change gedit preferences when logged in as root ( su ). opencraft Using Fedora 3 23rd September 2009 09:07 AM
gedit problems with root yellow Using Fedora 15 28th October 2008 06:29 PM


Current GMT-time: 14:13 (Tuesday, 02-09-2014)

TopSubscribe to XML RSS for all Threads in all ForumsFedoraForumDotOrg Archive
logo

All trademarks, and forum posts in this site are property of their respective owner(s).
FedoraForum.org is privately owned and is not directly sponsored by the Fedora Project or Red Hat, Inc.

Privacy Policy | Term of Use | Posting Guidelines | Archive | Contact Us | Founding Members

Powered by vBulletin® Copyright ©2000 - 2012, vBulletin Solutions, Inc.

FedoraForum is Powered by RedHat