[Solved] Can't xed admin:///etc/lsb-release

[johnywhy]

Question about this page:
https://sites.google.com/site/easylinux ... tomentries

This line
xed admin:///etc/lsb-release

gives this error

Code: Select all

(xed:6483): GLib-GIO-CRITICAL **: 14:26:07.986: g_dbus_proxy_new_sync: assertion 'G_IS_DBUS_CONNECTION (connection)' failed
(xed:6483): dconf-WARNING **: 14:26:08.312: failed to commit changes to dconf: The connection is closed
(xed:6483): dconf-WARNING **: 14:26:08.604: failed to commit changes to dconf: The connection is closed
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
Error creating proxy: The connection is closed (g-io-error-quark, 18)
** (xed:6483): WARNING **: 14:26:08.941: Operation not supported
Could not open the file admin:///etc/sysctl.conf.
xed cannot handle admin: locations.

To fix, i tried to install gvfs-backends
https://ubuntuforums.org/showthread.php?t=1278395

but it seems already installed:

Code: Select all

# apt-fast install gvfs-backends
gvfs-backends is already the newest version (1.36.1-0ubuntu1.1).

How to fix?
On fresh, updated install of Mint 19 xfce.

Cheers!
Johny

[gm10]

See if this helps:

Code: Select all

sudo chown -Rc $USER:$USER $HOME

[johnywhy]

hi gm10!

thx for quick reply.
i found i could add custom entries by editing /etc/grub.d/40_custom
eg

Code: Select all

menuentry "xslacko" {
    set root='(hd0,1)'
    linux /xslacko4.4frugal/vmlinuz pmedia=atahd psubdir=xslacko4.4frugal
    initrd /xslacko4.4frugal/initrd.xz
    }

that works for me!

So now 2 questions:
- do i need to pin the file, so updates don't overwrite it?
apt-mark hold base-files

- Does the original question in this thread indicate something broken in my Mint? (Can't xed admin:///etc/lsb-release)

THX

[gm10]

1. no, but in case of doubt just add your own file rather than edit the existing one
2. yes, but given the frequency of your threads I thought you break stuff for fun.

[johnywhy]

just add your own file

Awesome! Didn't know I could.

2. yes,

This is a fresh Mint installation. I tried

Code: Select all

sudo chown -Rc $USER:$USER $HOME

and got the same error.

I thought you break stuff for fun.

[gm10]

Awesome! Didn't know I could.

All the .d directories denote directories holding arbitrary configuration files, you can always add your own. Directory contents get sorted, that's why the convention is to put a number at the front to denote priority. Higher numbers will be processed later and thus parameters set there will have precedence over the same parameters set earlier.

This is a fresh Mint installation. I tried

Code: Select all

sudo chown -Rc $USER:$USER $HOME

and got the same error.

Hmm. I'm not sure exactly what the problem is unfortunately but it still feels user-environment related. Can you try going to Menu > Users and Groups > Add and create a user called sudo, then log out and switch to his account and see if you can do it from here? Let me know if it works or not. You can delete the account again afterwards same way you created it.

[johnywhy]

i solved it. You can't run it at su or sudo. You have to run it at logged-in user-prompt. Then you get a password popup.

feels user-environment related. create a user called sudo

Yep, I was trying to execute after su. That's the problem.

Fails:

Code: Select all

su
xed admin:///etc/lsb-release

It has to be executed without su. Ie, just run at the logged in user's prompt, not a su prompt. Then, you get a popup asking for admin password. Then the file loads properly.

DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=19
DISTRIB_CODENAME=tara
DISTRIB_DESCRIPTION="Linux Mint 19 Tara"

i confirmed with 3 user types: admin, desktop, and standard ("custom").

also, it doesn't work with sudo. Sudo doesn't even work at admin's prompt (who's a member of sudo group). Fails the same way:

Code: Select all

sudo xed admin:///etc/lsb-release

i could not tell you why this happens

(ps, by 'sudo', i mean real Linux sudo, not the fake sudo desktop you asked me to create.Btw, why did you have me name that test-desktop 'sudo'? Does that mean it's actual sudo? Seems risky to use same name.)

All the .d directories denote directories holding arbitrary configuration files, you can always add your own. Directory contents get sorted, that's why the convention is to put a number at the front to denote priority. Higher numbers will be processed later and thus parameters set there will have precedence over the same parameters set earlier.

Thanks for that!

THX

[gm10]

i could not tell you why this happens

I could but let's just say that you should never run graphical applications using sudo, ever, and you should forget that su exists. I vaguely remember now you were the guy wanting to run everything as root though so that may fall on deaf ears though.

So I'll just say that in order to save everyone including yourself some time, in the future try not to second guess guides and instructions from experienced members like Pjotr (that was his website you were linking). If he wanted you to run a command as root he would have told you so. Elevated privileges should be used sparingly.

(ps, by 'sudo', i mean real Linux sudo, not the fake sudo desktop you asked me to create.Btw, why did you have me name that test-desktop 'sudo'? Does that mean it's actual sudo? Seems risky to use same name.)

By default, users are added to a group that equals their name. So by asking you to create a user called sudo that user would automatically have been member of the sudo group. It's a little shortcut I like to use when troubleshooting others. There is no risk involved.

[johnywhy]

i could not tell you why this happens

I could

Please do

but let's just say that you should never run graphical applications using sudo

How about give me and others the benefit of your wisdom, so that we can become more knowledgeable linux users, and share the explanation. (if you're willing/able )

forget that su exists

i prefer to learn and be in control of my OS.

I vaguely remember now you were the guy wanting to run everything as root

Incorrect. It's the opposite: i'm the guy who doesn't want to run anything as root. That's why i login as Desktop user for daily usage.

to save everyone including yourself some time, in the future try not to second guess guides

Plz don't be mad. I apologize for trying to do the right thing. Did not mean to disrespect Pjotr or waste anyone's time. I thought linux was all about learning, experimenting, and being in control of one's OS-- and not just doing what you're told, not accepting, without question, the off-the-shelf OS that microsoft forces on you. I didn't realize Mint is the Microsoft of Linux

to create a user called sudo that user would automatically have been member of the sudo group.

That's what i thought. Oops, sorry, i second-guessed! i shall do as i'm told Clever trick!

There is no risk involved.

When i deleted the 'sudo' login account called 'sudo', i picked "Delete files". Since, as i correctly surmised, the sudo user and sudo group are one and the same, i was concerned that picking "Delete files" could impact the global OS sudo. Moreover, concerned anything i do in that sudo-desktop might impact the global OS-sudo. Dammit, there i go, trying to second guess again! Sorry!!

Thx for all help.

[johnywhy]

Update, found the reason GUI apps should not be run as sudo or su:

GUI apps may save session config info. They save it to the logged-in user's Home folder. Even if you run the app as root (su/sudo), the config is still saved to the logged-in user's Home. If you run a GUI app as root, then root will own the config file.

As a result, when you later run the app normally, as logged-in user, it will try to access the same config previously stored by root. Since those files will now be owned by su/sudo, the logged-in user won't be able to access them. Thus, the GUI app will fail to launch properly.

https://askubuntu.com/a/270019

Imo, this is a serious design flaw in the OS. It should be prevented somehow.

[gm10]

(you posted while I was writing this, posting it as is regardless)

I deserved some of that, but so did you. Let me clarify: Second-guessing as in trying to understand is perfectly fine and I commend it. Only way to learn. Second-guessing as in breaking stuff and then coming here asking for help just pointing to the guide you followed but NOT mentioning that you put your own spin on it is not. Had you done so, I could have told you the problem in my first reply rather than both of us having to take a detour.

As to sudo and GUI applications: The short answer is that it's imperfect. Your applications will run in a mixed user and root environment, and that can create problems. It's not even about GUI applications as such. That's just a rule of thumb. It's applications that access various parts of your user environment. The risks involved are that suddenly files in your $HOME folder will be root owned and your non-elevated applications cannot write to them anymore. That's what I initially suspected had happened and hence in my first reply the solution I suggested was a command that would turn ownership of all files in $HOME back to you. So I was at least in the ballpark with my initial error analysis.

The best suggestion I can give - and this is assuming you are in LM19 since you were following a guide for LM19 - is to run this and then in the future prefix commands you need elevated with gksudo instead:

Code: Select all

echo '/usr/bin/pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $@' > ~/.local/bin/gksudo;chmod u+x ~/.local/bin/gksudo

This is not 100% safe either, but it's the safest we currently got. The added bonus is that you won't be able to use it at a root shell.

In addition, as I had already said, you should not give any application root privileges unless it really really needs it. The xed text editor does NOT need them. That's why the admin:// handler exists. Rather than elevating the entire xed process to root privileges, you get to authenticate just for gaining write access to a root-owned file. Much more restricted, much safer, just how we like it. This process is handled by the polkit authorization API, I invite you to read up on it here, it's certainly something you ought to know since you seem interested in diving deeper into the system: https://www.freedesktop.org/software/po ... kit.8.html.

Now that handler does not work at a root shell or prefixed with sudo is because it's not set up for that for obvious reasons. The root shell/sudo authorization already gives you full system access, there is nothing you cannot do (or break). And that's also the reason why I discourage usage of su. People are already careless with usage of sudo, but at least that prompts for a password before each action.

[Pjotr]

Imo, this is a serious design flaw in the OS. It should be prevented somehow.

It's definitely no OS flaw. Simply only use root authority when it's both necessary and correct. That's all.

[johnywhy]

Thx for additional info. I didn't root xed as an 'experiment, to see if would would break something". i swear! Really did it without thinking. My bad for assuming. (suggestion, maybe don't assume when something breaks, it's cuz somebody was "experimenting" or "playing". That's what my grumpy impatient dad used to say, 40+ years ago )

the solution I suggested was a command that would turn ownership of all files in $HOME back to you.

Great idea! I think that's the fix in case my `su;xed` broke xed, but isn't a solution to the original aim, to edit the system file.

run this and then in the future prefix commands you need elevated with gksudo instead:

Code: Select all

echo '/usr/bin/pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $@' > ~/.local/bin/gksudo;chmod u+x ~/.local/bin/gksudo

Here's my attempt to analyse: It appears to reset environment variables associated with gksudo back to the logged-in user environment, and restores execution permission to the logged-in user. I think this is a workaround you're offering, in case user runs something as root? No, that's not right... To prevent mixed-environment issue? No... This writes environment variables to the gksudo command (to gksudo script?).... Or, appends a command, to execute whenever you do gksudo? .... or something

as I had already said, you should not give any application root privileges unless it really really needs it

as i said, i'm the guy who doesn't want to run anything as root. I've been criticized for taking that too far

the admin:// handler exists to authenticate just for gaining write access to a root-owned file.

When need to edit system files, i find it convenient to run Thunar (file manager) as root, and then browse/edit system files at will. I launch with `pkexec thunar`. Should that be `gksudo thunar` instead? I thought gksudo is a gnome thing. Does that mean it can only be used with gnome apps? Are all Mint xfce GUI apps gnome apps? i understand pkexec uses polkit, but this guy says pkexec ignores polkit config...? And, Mr. Een says "gksu(do) is gone in 19"

polkit authorization API, I invite you to read up on it

Yes, i have done a little polkit stuff already viewtopic.php?f=90&t=276052

It's definitely no OS flaw. Simply only use root authority when it's both necessary and correct. That's all.

If `sudo SomeGuiApp` can break the gui app, and if there's no reason to do it ever, then imho `sudo SomeGuiApp` should be an invalid command. It should return a helpful error (like "To run SomeGuiApp as root, use `pkexec SomeGuiApp`").

thx all, cheers!

[gm10]

That gksudo thing is suggested is just a pkexec wrapper. You can name that script whatever you like, I just named it gksudo because that's a command people are used to -- the original gksudo is no longer supported.

And I don't know about Thunar but in Caja and Nemo I can just right click and select to edit as root/administrator without having to run the file browser itself as root.

Regarding Polkit and that askubuntu link you found - you misunderstood him and he wasn't very clear to begin with. pkexec doesn't ignore polkit configuration but it's a crutch regardless and only necessary for applications that don't make proper usage of the polkit API themselves. xed's admin:// implementation is a crutch, too, with many limitations, but at least you don't need pkexec to run it. Proper editors will just ask for you authorization on demand.

[johnywhy]

Getting error with your workaround:

Code: Select all

$ echo '/usr/bin/pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $@' > ~/.local/bin/gksudo;chmod u+x ~/.local/bin/gksudo
bash: /home/johny/.local/bin/gksudo: No such file or directory
chmod: cannot access '/home/johny/.local/bin/gksudo': No such file or directory

That gksudo thing is suggested is just a pkexec wrapper. You can name that script whatever you like, I just named it gksudo because that's a command people are used to -- the original gksudo is no longer supported.

Ok, neat. Seems vaguely similar to your trick of creating a user called 'sudo'. I'm starting to see your style Personally, i'd prolly avoid using existing keywords that way, tho i can see why it makes sense here (since you're used to typing gksudo).

My new analysis

Code: Select all

$ echo '/usr/bin/pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $@' > ~/.local/bin/gksudo
$ chmod u+x ~/.local/bin/gksudo

- the echo directed to gksudo creates the script called gksudo, and writes your pkexec statement into the script.
- the pkexec statement sets the environment of the script to root, so that config-writes are done in the root home, instead of logged-in user home. (i don't see why that necessary, since pkexec already runs in root env, no?).
- $@ is the gui-app name passed into the script when the script is called.
- chmod gives local user execute-permission.

Hrm, pkexec man says:

the PKEXEC_UID environment variable is set to the user id of the process invoking pkexec. As a result, pkexec will not allow you to run X11 applications as another user since the $DISPLAY and $XAUTHORITY environment variables are not set.

So does that mean if i do pkexec thunar, configs are written to logged-in user, instead of root? So, i could break my thunar that way, same as doing sudo thunar can break thunar?

in Caja and Nemo I can just right click and select to edit as root/administrator without having to run the file browser itself as root.

Handy! i don't see that in Thunar, but wouldn't help anyway, in cases where the user doesn't even have read-access to a certain directory (which i've encountered, maybe cuz i run as Desktop user). Windows (shudder the thought, shutter the Windows) has "run as administrator" option on executables.

xed's admin:// implementation is a crutch, too, with many limitations, but at least you don't need pkexec to run it.

last stupid question (for the next 15 minutes at least): Is xed doing pkexec in the background, for admin://?

THX

[gm10]

Ok, neat. Seems vaguely similar to your trick of creating a user called 'sudo'. I'm starting to see your style Personally, i'd prolly avoid using existing keywords that way.

From a support giver point of view it's similar, yes. I try to minimize the possibility of user mistakes and simplifying the instructions I give them plays into that. But in this case I also have that script on my own system, because it's simply a useful thing to have no matter your background.

You will note I stressed it was only for LM19. On LM19 the gksudo command does not exist. Via the script you make it available again, which also helps you use code you find in some guides where they still use gksudo. Again, just simplifying things for the user. But as I said, you can call it whatever you like.

xed's admin:// implementation is a crutch, too, with many limitations, but at least you don't need pkexec to run it.

last stupid question (for the next 15 minutes at least): Is xed doing pkexec in the background, for admin://?

Not pkexec, no, but the polkit API is being used for this, yes.

[johnywhy]

many thx, if you have time, plz see error i'm getting with your workaround, above.

THX

[gm10]

sry, had missed that.

Code: Select all

$ echo '/usr/bin/pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $@' > ~/.local/bin/gksudo;chmod u+x ~/.local/bin/gksudo
bash: /home/johny/.local/bin/gksudo: No such file or directory
chmod: cannot access '/home/johny/.local/bin/gksudo': No such file or directory

You're the second guy I run into that doesn't have a ~/.local/bin directory in their user profile. Amended my script to account for that:

Code: Select all

mkdir -p ~/.local/bin;echo '/usr/bin/pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $@' > ~/.local/bin/gksudo;chmod u+x ~/.local/bin/gksudo

[MrEen]

You're the second guy I run into that doesn't have a ~/.local/bin directory in their user profile. You can always install it system-wide instead:

18.3 Xfce here and no ~/.local/bin directory either (share is the only folder in .local.)

[gm10]

18.3 Xfce here and no ~/.local/bin directory either (share is the only folder in .local.)

Thanks for the pointer. Just looked it up in the ISOs. Seems the $PATH addition is there in ~/.profile but the folder doesn't get created automatically for a new profile. Could be called a bug I guess. So if I just add an mkdir -p to my script to be on the safe side I'll be fine. Done. Cheers.