Dolphin issue

[Snowhog]

I could be wrong, but I think you could do the same with Dolphin; sudo -i and then launch Dolphin.

The issue as I understand it, is that you cannot 'start' Dolphin "as root", i.e., with kdesudo dolphin, as that gives dolphin 'root authority' but does so in your users environment, and that is the underlying problem.

[Qqmike]

Hi Snowhog. I tried that, but it won't work:

mike@mike-All-Series:~$ sudo -i
[sudo] password for mike: 
root@mike-All-Series:~# dolphin
Executing Dolphin as root is not possible.
root@mike-All-Series:~# exit
logout
mike@mike-All-Series:~$

Rhetorical: Is this why everyone turns to Krusader or mc? Is there no safe way to open/start/run Dolphin as root?

I still want to be sure that doing this is safe (avoiding issues of running graphicals with the wrong root permission commands):

sudo -i
krusader

Thanks for your input, everyone, so far (What? I haven't worn everyone out yet?)

[GreyGeek]

jerry@jerry-Aspire-V3-771:~$ sudo -i dolphin
[sudo] password for jerry:
Executing Dolphin as root is not possible.
jerry@jerry-Aspire-V3-771:~$ sudo -i
root@jerry-Aspire-V3-771:~# dolphin
Executing Dolphin as root is not possible.
root@jerry-Aspire-V3-771:~#

[kubicle]

Dolphin currently does not start as root whether you use sudo or a hatchet (it has been disabled in dolphin's code).

"sudo -i krusader" will start krusader as root (you can also use "kdesu" if you put or link "kdesu" in a directory that is in your $PATH [or alternatively use the full path to kdesu]). Whether this is safe is somewhat relative. Running *any* GUI app as root is inherently unsafe due to security vulnerabilities in the X server (this is the reason why running as root was disabled in dolphin), which could let (user installed) malware gain root access to your machine. This isn't really a problem if you don't have malware or malicious or incompetent users on your machine...and it obviously didn't come dangerous overnight (although it's a bit more of a hazard now that the vulnerabilities are more widely known).

I'm not terribly worried about running krusader as root (even though I'll gladly stop doing that once it is not necessary anymore), but then again I run a pretty tight ship on my machines. Whether anyone else is comfortable doing that, it's their call.

Just make sure you use the "-i" (or alternatively the "-H") option if you use sudo with GUI apps, it will protect your user's $HOME from root modification of ownerships (which can cause various issues...which people often both report and warn against).

[Qqmike]

kubicle: I believe the permissions were changed around 15.10 (or possibly 16.04), before that it was readable (but not writable) for all...IIRC.

Yeah, that's probably true. As I recall, I probably did do all my extensive ESP work in 14.04 using kdesudo dolphin. There's many reasons why you might want to get in there to do edits, or to make your own boot loader files (drag-drop work), or change a grub.cfg, or rename your favorite loader to be seen as the standard, default boot loader which is BOOTx64.efi (the UEFI firmware will read that as the default and use it, not knowing that it is actually your fav loader).

Thanks, kubicle, for all your tips and info in the above posts. I think I will consider this solved but, first, will write up a brief concluding summary, which I'll post within the hour.

Anyone get any other ideas or tips, please post them.

[Qqmike]

I'm going to consider this Solved. However, if anyone gets ideas or tips, please continue to post any thoughts.

Solved as follows (a summary -- mostly from kublicle -- I tested all the following):

First, this won’t work:
sudo chmod -v -R 777 /boot/efi
Output:
mode of '/boot/efi/EFI' changed from 0700 (rwx------) to 0777 (rwxrwxrwx)

Chmod won’t work on FAT32; it will not override the fstab permissions. The output of chmod looks good, but it doesn’t work.
Nor can you at CLI change directory (cd) into it and list files (ls): Permission Denied.

You CAN, however, do any of the following:

Issue at Konsole sudo -i, then use the command line to cd and ls into /boot/efi and see what’s there, and go from there with root permissions.

Or,

Issue sudo -i and open Krusader (as root):
sudo -i
krusader

Security note, kubicle (Post #19 above):
Just make sure you use the "-i" (or alternatively the "-H") option if you use sudo with GUI apps, it will protect your user's $HOME from root modification of ownerships (which can cause various issues...which people often both report and warn against).

Rod J, on an easy way to run Krusader as root:
I might add that the easiest way to run Krusader in root mode is to start a normal Krusader then click on Tools, "Start Root Mode Krusader", you then get a solemn warning about the dangers of doing so and a choice to exit if you wish.

Or,

(This also works but is not recommended by one of our resident experts)
Change the permissions in fstab, so every time you open Kubuntu, the ESP is mounted at /boot/efi with root permissions for everyone. As follows:

Before (this is the fstab entry written by the installer during installation of my Kubuntu 18.04.1):

[FONT=monospace][SIZE=3]# /boot/efi was on /dev/sda1 during installation[/SIZE][/FONT]
[FONT=monospace][SIZE=3]# This statement only gives read/write access to root:[/SIZE][/FONT]
 [FONT=monospace][SIZE=3]UUID=C896-1CFF  /boot/efi       vfat    umask=0077      0       1[/SIZE][/FONT]

After (after I edited it to gain permissions for everyone each time the ESP is mounted (at /boot/efi)):

[FONT=monospace][SIZE=3]# /boot/efi was on /dev/sda1 during installation[/SIZE][/FONT]
[FONT=monospace][SIZE=3]UUID=C896-1CFF  /boot/efi       vfat    umask=0000      0       1[/SIZE][/FONT]

I tested this, it works, but I now lean toward kubicle’s advice not to implement such a drastic measure.


Note:

Explains umask permissions in fstab.
http://www.omaroid.com/fstab-permiss...sks-explained/

Fstab Mask Permissions
The umask is the default for files and folders, if you want to customize files and folders’ permissions you should use fmask and dmask same use as the umask.
I was lost first finding the mask permissions are not like the octal permission codes passed to the chmod command, however I found this table really helpful understanding how the umask permissions work.

	0	1	2	3	4	5	6	7
r	+	+	+	+	–	–	–	–
w	+	+	–	–	+	+	–	–
x	+	–	+	–	+	–	+	–

It works as the normal octal permissions but subtracted from 7, and use the absolute value. for instance if you want to set the permissions to 0777 you will need to set it 0000 in the umask(e.g. umask=0000), if you want to set it to 0755 you will set it to 0022.
The first character represents that its an octal permissions
The second is for the owner
The third is the group
The last is for other or The World

(I couldn't remove that big line space following the above table.)

[Rod J]

I might add that the easiest way to run Krusader in root mode is to start a normal Krusader then click on Tools, "Start Root Mode Krusader", you then get a solemn warning about the dangers of doing so and a choice to exit if you wish.

My personal opinion on accessing anything in my system is that I want to be able to READ everything (which I find is great using Krusader's in-built file viewer) but I'm OK with leaving WRITE access to sensitive areas as root only. So, I want to read /boot (as it was before) but not necessarily write there as a normal user.

BTW, my understanding of all this tightening up of security as regards running GUI programs as root is because of changes coming with Wayland that doesn't allow gui root at all. Correct me if I'm wrong here.

[Qqmike]

Thanks, Rod. I added your 1st para. to my post #21:

I might add that the easiest way to run Krusader in root mode is to start a normal Krusader then click on Tools, "Start Root Mode Krusader", you then get a solemn warning about the dangers of doing so and a choice to exit if you wish.

- - - - - - - - - -

I want to be able to READ everything (which I find is great using Krusader's in-built file viewer) but I'm OK with leaving WRITE access to sensitive areas as root only.

That's probably the "normal" case. One big reason to Write is to goof around, experiment, so you can write how-to's about how the thing works! As I posted recently somewhere around here, my 14.04 ran so good--no problems--that I'd break my booting just to shake things up and have something to do-learn.