FedoraForum.org - Fedora Support Forums and Community
Results 1 to 15 of 15
  1. #1
    Join Date
    Mar 2010
    Location
    Newcastle-upon-tyne, UK
    Posts
    170

    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!

  2. #2
    Join Date
    Mar 2004
    Location
    In your closet
    Posts
    15,603

    Re: Gedit not working for root

    Try using su - instead of just su.
    Glenn
    The Bassinator

  3. #3
    motnahp00 Guest

    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.

  4. #4
    Join Date
    Mar 2004
    Location
    In your closet
    Posts
    15,603

    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

  5. #5
    Join Date
    Aug 2009
    Location
    Waldorf, Maryland
    Posts
    7,346

    Re: Gedit not working for root

    Quote Originally Posted by motnahp00
    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.

  6. #6
    motnahp00 Guest

    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
    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.

  7. #7
    Join Date
    Mar 2010
    Location
    Newcastle-upon-tyne, UK
    Posts
    170

    Re: Gedit not working for root

    cheers peeps... will give that a shot!

  8. #8
    Join Date
    Apr 2010
    Location
    Hungary
    Age
    27
    Posts
    6

    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

  9. #9
    Join Date
    Mar 2010
    Location
    Newcastle-upon-tyne, UK
    Posts
    170

    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...

  10. #10
    Join Date
    Mar 2011
    Posts
    28

    Re: Gedit not working for root

    Quote Originally Posted by Shugs81
    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.

  11. #11
    Join Date
    Mar 2004
    Location
    In your closet
    Posts
    15,603

    Re: Gedit not working for root

    On my laptop running F15 Alpha.
    [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

  12. #12
    Join Date
    Aug 2009
    Location
    Waldorf, Maryland
    Posts
    7,346

    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

  13. #13
    Join Date
    Aug 2010
    Location
    Al Ain, UAE
    Posts
    2,007

    Re: Gedit not working for root

    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.

  14. #14
    Join Date
    Mar 2011
    Posts
    28

    Re: Gedit not working for root

    Quote Originally Posted by flyingfsck
    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:

    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.

  15. #15
    Join Date
    Mar 2010
    Location
    Newcastle-upon-tyne, UK
    Posts
    170

    Re: Gedit not working for root

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

Similar Threads

  1. F14, can't run gedit as root
    By twohot in forum Using Fedora
    Replies: 44
    Last Post: 29th November 2011, 07:41 AM
  2. [SOLVED] Gedit Root Error
    By dmachop in forum Using Fedora
    Replies: 2
    Last Post: 1st January 2011, 03:34 PM
  3. [SOLVED] gedit can't change font size as root
    By errorxp in forum Using Fedora
    Replies: 2
    Last Post: 27th August 2010, 11:25 AM
  4. Replies: 3
    Last Post: 23rd September 2009, 09:07 AM
  5. gedit problems with root
    By yellow in forum Using Fedora
    Replies: 15
    Last Post: 28th October 2008, 06:29 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •