Page 1 of 3 123 LastLast
Results 1 to 10 of 24

Thread: open Dolphin in KDE from root shell

  1. #1

    Question open Dolphin in KDE from root shell

    I wonder what's the fastest or most convenient way to open something in KDE as my default user when I have done a "sudo su" and I'm working in a root console/shell.

    I know currently I cannot open anything:

    root@xen-pc:~# dolphin .
    dolphin: cannot connect to X server


    As a tryout I can use different sudo commands:

    Nothing really works. Su'ing to my regular user from the root prompt (that resulted from my regular user) also doesn't work.

    I have to go back (exit the root prompt) but that means I also usually leave the current working directory, and the whole point is usually to execute the command in root's current working directory.

    Also

    kdesu konsole

    will open me a root console, but subsequent

    dolphin .

    will again create an error

    No protocol specified
    dolphin: cannot connect to X server :0

    How can I get the root user connect to my normal user's X?


  2. #2

    Default Re: open Dolphin in KDE from root shell

    Quote Originally Posted by xen82 View Post
    I wonder what's the fastest or most convenient way to open something in KDE as my default user when I have done a "sudo su" and I'm working in a root console/shell.

    I know currently I cannot open anything:

    root@xen-pc:~# dolphin .
    dolphin: cannot connect to X server


    Don't use "sudo su" to switch to root. (IMHO that's nonsense anyway, as "su" alone is sufficient, no need for an additional "sudo"...)
    Use "su -" instead, and you should also be able to start applications.

    But of course they will run as root then, not as standard user.

    To run something as normal user from a su shell, switch to that user first ("su - username"), or use "kdesu -u username xxx" (if you omit the "-u username", it defaults to root).

    For certain applications you will get DBUS errors (applications run by another user will not find your user's DBUS session), use "dbus-launch dolphin" or similar in that case.

    Code:
    kdesu konsole

    There's no need to run Konsole as root.
    Just switch to the "Root Shell" profile (you might have to enable it in "Manage Profiles"), or use the "Terminal - Super User Mode" application launcher entry.
    But that also only runs "su -"...

    Btw, for running dolphin as root, there should be an entry "Filemanager - Super User Mode" in the application launcher.
    Last edited by wolfi323; 20-Aug-2015 at 08:40.

  3. #3

    Exclamation Re: open Dolphin in KDE from root shell

    My god, it actually works.

    Why does su work and sudo does not??..

    The reason I use sudo su is because then I can use ... well, normally, on a different system, I can use my user's password instead of my root password. At the moment they are identical so perhaps it makes no sense, but on Ubuntu systems it is very much a different thing. On an Ubuntu system there is not even a default root password.

    Also sudo remembers your password so the next time you get frustrated and do "sudo su" to get out of the madness of having to use sudo all the time, you won't need to type your password, whereas with su you need to :D. And I like the idiom better.

    But why doesn't it work with sudo?.

    How come sudo prevents it from working?

    On most of my systems the root user has a very long password, or at least a long password, and I would not want to use it all the time. It even kills it when you do "sudo su - xen" (to go back to your current user) :P. Lol. Sudo kills all X connections/abilities.

    I know on openSUSE by default sudo uses the root password, but of course you can change that.

  4. #4

    Default AW: Re: open Dolphin in KDE from root shell

    Quote Originally Posted by xen82 View Post
    My god, it actually works.

    Why does su work and sudo does not??..
    Because sudo doesn't setup a full environment, it even filters out things from the user's environment (like e.g. the $DISPLAY variable that tells applications where to open their windows) for security reasons.

    The reason I use sudo su is because then I can use ... well, normally, on a different system, I can use my user's password instead of my root password.
    Yeah, that's how Ubuntu is configured.
    On openSUSE, sudo needs the root password too.

    I know that using "sudo su" is a common advise on Ubuntu to start a root shell. But still IMHO it makes no sense. Why run su to switch to root when you are already root? (I.e. why run su as root to switch to root?)
    "sudo sh" would make more sense...

    Anyway, that's just nitpicking from my side, not directed at you. Just ignore that.

    On an Ubuntu system there is not even a default root password.
    I know.
    And I think that doesn't make sense either...

    Also sudo remembers your password so the next time you get frustrated and do "sudo su" to get out of the madness of having to use sudo all the time, you won't need to type your password, whereas with su you need to .
    sudo only remembers the password for 5 minutes.
    And if you are logged in as root (with either "sudo sh", "sudo su", or "su"), you don't need the root password any more anyway.

    But why doesn't it work with sudo?.
    See above.

    How come sudo prevents it from working?
    Have a look at /etc/sudoers.

    On most of my systems the root user has a very long password, or at least a long password, and I would not want to use it all the time.
    And what's the point of having a very long root password if the user can switch to root with his/her short, insecure password anyway?
    Last edited by wolfi323; 20-Aug-2015 at 10:29.

  5. #5

    Talking Re: AW: Re: open Dolphin in KDE from root shell

    Quote Originally Posted by wolfi323 View Post
    Because sudo doesn't setup a full environment, it even filters out things from the user's environment (like e.g. the $DISPLAY variable that tells applications where to open their windows) for security reasons.
    I just tried to cancel that in the /etc/sudoers but to no effect yet. I turned reset_env into !reset_env. And although it appears my complete environment is now present when I do sudo, there is still no change in the behaviour. Actually, it gives a slightly different error I believe: it explicitly mentions it cannot connect to :0.

    I know that using "sudo su" is a common advise on Ubuntu to start a root shell. But still IMHO it makes no sense. Why run su to switch to root when you are already root? (I.e. why run su as root to switch to root?)
    "sudo sh" would make more sense...
    It makes more sense because for some reason it is a better idiom. I used to write sudo bash from time to time but su is shorter. And su does everything bash does, and probably more. It's just fun. And it's easier to type than sudo -i or whatever.

    I know.
    And I think that doesn't make sense either...
    The funny thing is that if you make such remarks on e.g. Kubuntu forums, you get basically treated like an idiot for saying that there are reasons to have a root password/account. For some reason everyone who is invested in a product is going to defend that product when you think it is off.

    I prefer to have a root password for a number of reasons:
    - I want to be able to log in to a TTY (cltr-alt-f2)
    - if you ....mess up the sudoers file, you're ....screwed
    - if you ....mess up your groups, you are ....screwed

    Both these things actually happened to me. I had commented out a line in sudoers and apparently I needed double ## so sudo failed to work after that.

    And one time I had used usermod -G without the -a, and that is my method of adding a group to a user. So my user was suddenly without the sudo group. And hence I couldn't sudo anymore, but I only found out after a reboot.

    And then you get treated like an idiot for "using a command you don't know how to use".

    And there are more reasons of course. Even the Ubuntu docs state that on machines where regular users come from e.g. LDAP, it is required to have a local user called root, at least. And this is true for local systems as well, the root user is just a useful and important fallback mechanism. And su always works.

    sudo only remembers the password for 5 minutes.
    Heh, okay.

    And if you are logged in as root (with either "sudo sh", "sudo su", or "su"), you don't need the root password any more anyway.
    Still I don't like su'ing. I have nightmares from a Synology system where regular "su" actually doesn't work, you need /bin/su because the other su links to /opt/bin/su .

    LOL!.

    Busybox system.

    See above.

    Have a look at /etc/sudoers.
    Tried that, no difference. Maybe try harder or check the web.... :/.

    And what's the point of having a very long root password if the user can switch to root with his/her short, insecure password anyway?
    Mostly for exposure. I just installed a VPS somewhere. First thing that happens, like almost right from the start, you get people doing e.g. dictionary attacks on the root user. Now the funny thing is that it is a Debian host and apparently the root user is disallowed from SSH. So it doesn't work (for them) anyway but it's kinda fun to see like 3000 lines of failed SSH root login attempts after one night. Root user is always more exposed because it is a common name and hence more targetted than your regular user.

    Without knowledge, it is hard to do any form of automated attack on a user you don't know exists. They call it security by obscurity but it's important.

  6. #6

    Default Re: open Dolphin in KDE from root shell

    Quote Originally Posted by xen82 View Post
    I just tried to cancel that in the /etc/sudoers but to no effect yet. I turned reset_env into !reset_env. And although it appears my complete environment is now present when I do sudo, there is still no change in the behaviour. Actually, it gives a slightly different error I believe: it explicitly mentions it cannot connect to :0.
    Yes. You need to allow root to open a window too, e.g. "xhost +" (turns off all restrictions, i.e. all users are allowed to open windows in your X session) or "xhost si:localuser:root" to only allow it for root on the local system.

    We had a lengthy thread here about this a while ago.

    Oh, and as mentioned already, you probably also will have problems connecting to the user's DBUS session which is required by modern desktop environments/toolkits.

    It's probably not worth the effort...

    You can configure kdesu to use sudo instead of the default su though.
    It respects the settings in /etc/sudoers then (e.g. require the user password instead of the root password, or require no password at all).
    And it's designed to run graphical applications as different user (including root) in the same X session.

    It makes more sense because for some reason it is a better idiom.
    How is "sudo su" a better idiom than "sudo sh"?

    I used to write sudo bash from time to time but su is shorter.
    Well, "sudo sh" is the same length as "sudo su".
    And "su" is shorter as "sudo su" too.

    And su does everything bash does, and probably more.
    "su" doesn't do *anything* that bash does, it only switches to root.

    It's just fun. And it's easier to type than sudo -i or whatever.
    I'd say "su" is easier to type than "sudo su"...
    And "sudo sh" (which actually runs bash as root) is the same as "sudo su" regarding this.

    But use what you want to use. I don't care and have no problem with it...

    Without knowledge, it is hard to do any form of automated attack on a user you don't know exists. They call it security by obscurity but it's important.
    Well, as you wrote: disallow root login via remote.
    If someone has physical access, he can get into the system anyway, without *any* username/password.
    Last edited by wolfi323; 20-Aug-2015 at 11:49.

  7. #7

    Default Re: open Dolphin in KDE from root shell

    Quote Originally Posted by wolfi323 View Post
    You can configure kdesu to use sudo instead of the default su though.
    It respects the settings in /etc/sudoers then (e.g. require the user password instead of the root password, or require no password at all).
    And it's designed to run graphical applications as different user (including root) in the same X session.
    Aye, already read about that.

    How is "sudo su" a better idiom than "sudo sh"?
    It sounds better for a start. You're typing the same letters twice, which is easy. And sudo sh actually doesn't do the same thing as sudo bash. SH is still a different shell -- on OpenSUSE it may link to bash, but on debian it links to dash, which you don't want as an interactive shell (trust me :P).

    So to stay equivalent on each platform, I have to do sudo su because it runs my default shell. Su, namely, will run bash. So your statement that su doesn't do anything that bash does, is incorrect, because it runs bash.

    Well, "sudo sh" is the same length as "sudo su".
    And "su" is shorter as "sudo su" too.
    You don't use su because you want to use your user password, and because it is a habit and a custom to write sudo in order to execute temporary commands. Single commands. So the workflow is to use sudo constantly for small things, and then if you need a bigger thing, you're in the same rhythm as every other command, which is to do it with sudo.

    sudo try something
    sudo try something else
    ****!
    sudo su.

    hahaha.

    "su" doesn't do *anything* that bash does, it only switches to root.
    that was incorrect, in the sense of it chaining into bash.

    I'd say "su" is easier to type than "sudo su"...
    And "sudo sh" (which actually runs bash as root) is the same as "sudo su" regarding this.
    Only on OpenSUSE, and not with the same prompt.

    But use what you want to use. I don't care and have no problem with it... rotfl!
    Good, I like a man that can laugh :P :P.

    Laugh on, brother....

    Well, as you wrote: disallow root login via remote.
    If someone has physical access, he can get into the system anyway, without *any* username/password.
    Disallowing root login is not always an option, for instance my (Syn) system needs a root login to open SSH tunnels apparently... :-/. Even then, if you had multiple users that had admin access ---- and I believe the singular "root as superuser" system is deeply flawed and primitive. I often crave a form of in-between solution (such as an "admin" user or the like, or whatever) because I find myself having to use root ALL THE TIME.

    You are constantly adding yourself to groups (such as www-data) and doing chmod g+w -R <something> just so your regular user can write to e.g. data directories of web applications. These data directories are mostly not accessible to world (which is logical and obvious) but because they run under their own user, and the group write mode is never set, and you can of course su to that user but only when you're already root (so you don't mess up permissions....) ..... you find yourself constantly needing root to do the most regular of things, such as manually moving files into or out of such a data dir. ([ I am currently just transforming a collection of FLAC archives to MP3 with a few quick scripts because there is hardly any room on that server. Yes I need read access to that data dir. ]). If I had an admin user that had the same privileges as a certain set of users (for example, squid, www-data, privoxy, postgres, that sort of thing) --- so you'd just include those users into that admin user, then you wouldn't have to constantly deal with root or change group permissions.

    I any case, if, in the current system, you have multiple admins, each with their own (weaker) password, then, although any exploit targetted as one of those users would grant superuser access to the system (as it is, at the deepest level, the 'root' level) (in this primitive setup) -- normally such sudo access would be logged. There would be an audit log. It would, unless the attacker (or the malicious ;-) admin) were to falsify the audit log (not something you always want to do; hence a protection) give a clue as to what is happening and why. It is a level of protection. You can even, potentially, theoretically, ensure that the root user has no access to the audit log. For example by storing it on a remote machine that is disconnected from the real current system. Now everything you do after sudo su is not auditted, but still, it could be and would grant a measure of protection or verifyability. If you were to log in directly to root, that would basically be your user, there is no history of "dude became root".

    It makes no sense to track any logins from any other users because you have the required credentials to become root, it is not tied to any other user account if you log in directly to root.

    And I guess this goes on and on, as it stands I believe the system is just perfect as far as perfection goes: make one difficult to access super account, but grant easier access to people who have been authorized. I think it is a good model.

    I guess that's the Ubuntu model, I just disagree with them going the other extreme.

    Their standpoint is "a regular user should never need to do these things that you profess you do or need to do." I believe they have this sentiment about what a "casual user" is. Some kind of computer nitwit that doesn't exist but still needs to use Ubuntu.

    The whole idea of people 'needing' to use Linux/Ubuntu is madness anyway. Everyone does it for its own reasons and if those reasons are not there, then you shouldn't even be doing it, that's what I believe.

    But since they have a bit of a (large bit of a) feeling that Ubuntu or (any derivatives) should be 'better' than e.g. Windows and that IF ONLY PEOPLE WOULD UNDERSTAND they'd come FLOCKING to Ubuntu/Kubuntu/Ubuntu Gnome/whatever. That it is only an educational effort that's required.

    While personally I wouldn't give Linux to anyone I knew (apart from a few) and I'd rather give OpenSUSE than the supposedly easier Ubuntus. There is much more solid documentation on OpenSUSE, for a start.

    If someone has physical access, he can get into the system anyway, without *any* username/password.
    Actually, that's rather hard as he'd run into an encryption prompt :P.

    You're talking of init=/bin/bash and that sorta stuff. Doesn't work. Currently my systems have a visible boot partition, but it is also possible to encrypt /boot and 'chainload' into the regular system using a key you put into the initrd/initramfs. So you can have one big encrypted LVM and you can't totally see what's inside it. Grub understands LUKS and I believe also truecrypt. The issue normally is that then you need to enter your password twice; once for grub and once for initrd, so you use a keyfile in the initrd so that you won't need the password again. Currently someone could at least (or at most) read the initramfs to see what's inside (not much use though) but any information leak is a bad information leak. Your boot partition also reveals what kind of systems you have installed (as normally all the kernels would be there) and since you're not using grub for encryption, the grub prompt also displays those systems, unless you boot into your main system first and then boot on into the next.

    Which is still possible. There is something called Kexec that allows you to boot into a next kernel. I never tried it yet, rebooting was too costly for me at that time. Linux is a crazy thing to explore. If you do it well, you can hide much, even if the system itself is not very... amenable to being used for security. Creating secure setups with a good level of plausible deniability is too difficult given current tools and states of affairs.

    Anyway.

  8. #8
    Join Date
    Nov 2009
    Location
    West Virginia Sector 13
    Posts
    15,703

    Default Re: open Dolphin in KDE from root shell

    Here is the thing, openSUSE is Linux but it is not Ubuntu Linux. Ubuntu made some changes to how a normal Unix/Linux systems works. Particularly in the root account. Personally I never use sudo I just get root privileges with su - . From then on I'm root until I exit that root shell. no typing sudo on each line

    I will not argue which way is better just that all other Unix/Linux OS's handle the root question the same with Ubuntu and derivatives being the odd men out.

    If you plan to use openSUSE learn the openSUSE way. Don't try to force the Ubuntu model on it. You can mod the sudoer file and get somewhat the same effects but it is not exactly the same. Better to learn the preferred way of the OS you are using rather then to force it to be some other thing.

    sudo su would open a new shell/thread which sudo alone would not do. sudo does not spawn a new thread and shell su does.

    note that su with out the dash gives root permissions but the environment is for the most part the user's the dash changes the environment to root's environment

  9. #9

    Default Re: open Dolphin in KDE from root shell

    Sorry, I don't really want to continue this discussion.
    It's completely off-topic and unrelated to your original problem anyway.

    Use "sudo su" and be happy, as I already indicated.


    Just a few things:
    And sudo sh actually doesn't do the same thing as sudo bash. SH is still a different shell -- on OpenSUSE it may link to bash, but on debian it links to dash, which you don't want as an interactive shell (trust me ).
    su does not explicitly run bash, it runs the shell specified for the user, i.e. root. This might also be dash or whatever.
    And bash might be a symlink to something else too.

    You don't use su because you want to use your user password, and because it is a habit and a custom to write sudo in order to execute temporary commands. Single commands. So the workflow is to use sudo constantly for small things, and then if you need a bigger thing, you're in the same rhythm as every other command, which is to do it with sudo.
    And what's this got to do with "sudo su" vs. "sudo sh" vs. "sudo bash"?

    As I wrote, if you want to run graphical applications as different user/root, use kdesu. That behaves similar to sudo, i.e. it remembers the password for 5 minutes as well.

    Actually, that's rather hard as he'd run into an encryption prompt .

    You're talking of init=/bin/bash and that sorta stuff. Doesn't work.
    It works by default.
    Yes, if your disk/boot loader is encrypted it will be not so easy or even impossible.

    But what's this got to do with sudo, or whether sudo asks for the root or user password, anyway?
    And you can disable explicit root login without disabling the root account itself.

    and I believe the singular "root as superuser" system is deeply flawed and primitive. I often crave a form of in-between solution (such as an "admin" user or the like, or whatever) because I find myself having to use root ALL THE TIME.
    That's why polkit exists, I suppose. You can set that up so that a single user (or even a selected list of users, that are not members of a particular group) can act as if he were root (with having to enter his own passoword or even without having to enter a password), and there's a "sudo" like command included too (pkexec). All in all its not dissimilar to sudo, but more flexible, as its rules are written in JavaScript.
    Last edited by wolfi323; 20-Aug-2015 at 13:35.

  10. #10

    Default Re: open Dolphin in KDE from root shell

    Quote Originally Posted by gogalthorp View Post
    Here is the thing, openSUSE is Linux but it is not Ubuntu Linux. Ubuntu made some changes to how a normal Unix/Linux systems works. Particularly in the root account. Personally I never use sudo I just get root privileges with su - . From then on I'm root until I exit that root shell. no typing sudo on each line

    I will not argue which way is better just that all other Unix/Linux OS's handle the root question the same with Ubuntu and derivatives being the odd men out.

    If you plan to use openSUSE learn the openSUSE way. Don't try to force the Ubuntu model on it. You can mod the sudoer file and get somewhat the same effects but it is not exactly the same. Better to learn the preferred way of the OS you are using rather then to force it to be some other thing.

    sudo su would open a new shell/thread which sudo alone would not do. sudo does not spawn a new thread and shell su does.

    note that su with out the dash gives root permissions but the environment is for the most part the user's the dash changes the environment to root's environment
    My dear friend,

    It is not up to you how I shall use OpenSUSE Linux, I think, and most rightly believe.

    I am not forcing any model on anything, since it is my own system, and I am at the right to modify it anyway I wish, I so believe.

    Just as people at Kubuntu would be saying "don't force the OpenSUSE model on Kubuntu" you are now saying the same thing, except in reverse.

    Once I have modded the sudoer file I believe it is entirely the same. Exactly entirely the same. There is no difference whatsoever between Ubuntu and OpenSUSE once you have installed the root password (in Ubuntu) and the sudo-uses-user-password (in OpenSUSE) apart from perhaps the mechanics in KDE.

    After all, Kubuntu sports kdesudo but even that is installable, I believe. However OpenSUSE's KDE alread prompts you for user passwords when required, there is not much difference. Kubuntus are opponents of doing "kdesude kate" and I'm not much a fan of kate. However "kdesu kwrite" does the exact same thing. Where is the difference really apart from believing that you are part of some different subculture?.

    The "model" that "OpenSUSE" or "the rest of the Linux world" uses also came about by user choice. Why should I not be the one to do the same? I also make user choice. It is development, and I am always developing, and I cannot be bound by any constrictions or policies that are not my own. Why should I accept them if accepting them would mean to cease development and change?.

    After all, I cannot change the choices of another, nor would I want to, but I can change my own choices and develop further in that. I do not have to take the choices of another as my own, as I could never grow in them, but only in my own. I cannot grow in the choices of another because I cannot make choices for or WITH the other. I cannot use the other to make life move ahead. I can only use myself to make life move ahead. So I need to make my own choices irrespective of what another is doing.

    Regards...

    Oh and I know sudo does not spawn a new thread (process), because sudo doesn't do anything on its own. That's why it works so well in conjunction with su. Although, of course, you will see two processes listed in the process view: one for sudo <command> and one for the command itself.

    Regards.

Page 1 of 3 123 LastLast

Posting Permissions

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