Welcome!

The kernel problem with recent updates has been solved. Find the solution here

Important information
-- Required MX 15/16 Repository Changes
-- Information on torrent hosting changes
-- Information on MX15/16 GPG Keys
-- Spectre and Meltdown vulnerabilities

News
-- Introducing our new Website
-- MX Linux on social media: here

Current releases
-- MX-18.3 Point Release release info here
-- Migration Information to MX-18 here
-- antiX-17.4.1 release info here

New users
-- Please read this first, and don't forget to add system and hardware information to posts!
-- Here are the Forum Rules

Hostname and the death of sudo

Help for Current Versions of MX
User avatar
thomasl
Forum Regular
Forum Regular
Posts: 190
Joined: Sun Feb 04, 2018 10:26 am

Hostname and the death of sudo

#1

Post by thomasl » Mon Apr 15, 2019 11:56 am

I have a frugal install that lives on the boot SSD of three different PCs, with the exactly same versions of linuxfs on all three PCs. For all three PCs I have a line in my grub boot config that gives an explicit hostname on the kernel command line (say hostname=PCone or PCtwo or PCthree). Depending on the hostname I call different init scripts in my .zshrc in order to initialise these PCs. This works perfectly well.

I have the exact same frugal install on a USB stick with a line that says hostname=unknown. Normally I boot this on other machines but sometimes I boot the USB on, say PCone (of course the init script for PCone then doesn't run automatically but I can do that manually if required).

I also tried to change the hostname from unknown to PCone by calling

Code: Select all

sudo hostname PCone
and copying the new hostname into /etc/hostname.

And this seems to work...but when I want to do a persist-save later on this doesn't work anymore: no error, no warning -- but also no save . Further investigation leads to sudo being the probable culprit. sudo apparently doesn't work when /etc/hostname has been changed (simply changing /etc/hostname back to unknown does the trick). I have googled left right and centre but none of the pages with possible solutions (ie editing /etc/hosts) does work.

It's not really a big deal but it's a still a puzzling thing. Has anyone got an idea what might be the problem here?
Dual-boot MX17.1/64 frugal root persistence + Windows 7 on Lenovo Edge72 i5-3470S/12GB and Tosh R950 i5-3340M/8GB
I used to think that good grammar is important. Now I know that good wine is importanter.

User avatar
fehlix
Forum Veteran
Forum Veteran
Posts: 4212
Joined: Wed Apr 11, 2018 5:09 pm

Re: Hostname and the death of sudo

#2

Post by fehlix » Mon Apr 15, 2019 12:21 pm

In order to not confuse "sudo" you need to have identical names in /etc/hostname and within /etc/hosts for the loopback address. Example:

Code: Select all

$ head -2 /etc/host{s,name}
==> /etc/hosts <==
127.0.0.1	localhost
127.0.0.1       mx182

==> /etc/hostname <==
mx182
Reason: sudo authetication mechanims caintains network related rules. Even if you setup within the sudoers-rulset to apply the rule for "all" hosts, it consults the sudoers-rulest after it check's the corrent hostname within the network and fails if not found or not found as "localhost".
:puppy:
Gigabyte Z77M-D3H, Intel Xeon E3-1240 V2 (Quad core), 32GB RAM,
GeForce GTX 770, Samsung SSD 850 EVO 500GB, Seagate Barracuda 4TB

User avatar
thomasl
Forum Regular
Forum Regular
Posts: 190
Joined: Sun Feb 04, 2018 10:26 am

Re: Hostname and the death of sudo

#3

Post by thomasl » Mon Apr 15, 2019 12:37 pm

@fehlix: thanks for that... alas I already had tried this (ie editing /etc/hosts) and it didn't work at all. Either I did something utterly stupid (so I will retry later today) or there's more to it than meets the eye.
Dual-boot MX17.1/64 frugal root persistence + Windows 7 on Lenovo Edge72 i5-3470S/12GB and Tosh R950 i5-3340M/8GB
I used to think that good grammar is important. Now I know that good wine is importanter.

User avatar
Head_on_a_Stick
Forum Regular
Forum Regular
Posts: 420
Joined: Sun Mar 17, 2019 3:37 pm

Re: Hostname and the death of sudo

#4

Post by Head_on_a_Stick » Mon Apr 15, 2019 12:47 pm

The Debian Reference recommends using 127.0.1.1 instead:

https://www.debian.org/doc/manuals/debi ... resolution
"Individual appropriation is neither just nor serviceable. All belongs to all." — Peter Kropotkin

User avatar
thomasl
Forum Regular
Forum Regular
Posts: 190
Joined: Sun Feb 04, 2018 10:26 am

Re: Hostname and the death of sudo

#5

Post by thomasl » Mon Apr 15, 2019 1:31 pm

I have now had an opportunity to re-test editing the /etc/hosts file (as I said I tried this before) and this definitely does not solve the problem. Neither 127.0.0.1 nor 127.0.1.1 makes sudo work again so this seems to be a solution in some cases but not in this case.

However... during testing this I realised that, although persist-save would not work in the X session, the call to save to the persistence file does work during shutdown.

So I went into a virtual console (ie ctrl-alt f1) and tested persist-save there... and strangely it does work there. Not at all sure why it does so though. :bagoverhead:

And... it also starts to work after I deleted my ~/.Xauthority file, logged out and logged in again.

Go figure.
Dual-boot MX17.1/64 frugal root persistence + Windows 7 on Lenovo Edge72 i5-3470S/12GB and Tosh R950 i5-3340M/8GB
I used to think that good grammar is important. Now I know that good wine is importanter.

User avatar
fehlix
Forum Veteran
Forum Veteran
Posts: 4212
Joined: Wed Apr 11, 2018 5:09 pm

Re: Hostname and the death of sudo

#6

Post by fehlix » Mon Apr 15, 2019 1:56 pm

Not clear I understand , when you say sudo is not working. Any error message ?
what would this give:

Code: Select all

id -u ; sudo -K && sudo id -u
Do you get an error message or any other indication to proof/verfiy sudo is not working?
Gigabyte Z77M-D3H, Intel Xeon E3-1240 V2 (Quad core), 32GB RAM,
GeForce GTX 770, Samsung SSD 850 EVO 500GB, Seagate Barracuda 4TB

User avatar
BitJam
Forum Veteran
Forum Veteran
Posts: 3341
Joined: Sat Aug 22, 2009 11:36 pm

Re: Hostname and the death of sudo

#7

Post by BitJam » Mon Apr 15, 2019 4:46 pm

Do I understand correctly that using the "hostname=xxx" boot parameter works fine and the problem only occurs when you use the "hostname xxx" command from within X without logging out and logging back in?
Will I cry when it's all over?
When I die will I see Heaven?

User avatar
thomasl
Forum Regular
Forum Regular
Posts: 190
Joined: Sun Feb 04, 2018 10:26 am

Re: Hostname and the death of sudo

#8

Post by thomasl » Tue Apr 16, 2019 5:39 am

@fehlix: As already stated, there's no error or warning given. And I assume sudo doesn't work because applications (like persist-save or geany) started via sudo (or requiring root) simply don't work. However, it seems that this is only true for things that require a GUI. Commands that wholly run in the terminal window actually seem to work.

Code: Select all

1~>id -u ; sudo -K && sudo id -u
1000
[sudo] password for thomasl: 
0
1~>
The output of those commands is the same, whether hostname is the original or has been changed.

@BitJam: Yes. When booted with hostname=XXX or hostname=YYY there's never a problem. This only happens once I change the hostname on a running system.

As I have discovered yesterday, logging out and logging in again seems to "repair" the problem. And as I have learned just yet, it's not even necessary to delete .Xauthority beforehand, a simple logout/login does the trick.

So in a sense, this is solved though I do not understand the reasons why this is happening.
Dual-boot MX17.1/64 frugal root persistence + Windows 7 on Lenovo Edge72 i5-3470S/12GB and Tosh R950 i5-3340M/8GB
I used to think that good grammar is important. Now I know that good wine is importanter.

User avatar
fehlix
Forum Veteran
Forum Veteran
Posts: 4212
Joined: Wed Apr 11, 2018 5:09 pm

Re: Hostname and the death of sudo

#9

Post by fehlix » Tue Apr 16, 2019 4:35 pm

thomasl wrote:
Tue Apr 16, 2019 5:39 am
And I assume sudo doesn't work because applications (like persist-save or geany) started via sudo (or requiring root) simply don't work. However, it seems that this is only true for things that require a GUI.
Starting GUI X-apps via sudo is a problematic idea, as not always a clean root-environment is prepared and permission and ownership mixture between real and effective user can happen. In worst cases session login is blocked .
Example: running "sudo geany", will make geany save settings within users-geany settings, and will change permissions and ownership of those settings files to root, in addition to security and .Xauthority related permission hicups.
So if starting X-apps with sudo, will prepare you system to get in trouble. X-apps which require root shall be started either with pkexec or su-to-root ( which in turn call gksu).
In theory you can , but you need to make sure that no settings nor files get written into real users home. So minimum requirement would be to start X-app with "sudo -H ..." , so you make sure root's home is set properly as other wise you end up root taking over partially your home ownership.
:puppy:
Gigabyte Z77M-D3H, Intel Xeon E3-1240 V2 (Quad core), 32GB RAM,
GeForce GTX 770, Samsung SSD 850 EVO 500GB, Seagate Barracuda 4TB

User avatar
BitJam
Forum Veteran
Forum Veteran
Posts: 3341
Joined: Sat Aug 22, 2009 11:36 pm

Re: Hostname and the death of sudo

#10

Post by BitJam » Tue Apr 16, 2019 5:01 pm

fehlix wrote:
Tue Apr 16, 2019 4:35 pm
Starting GUI X-apps via sudo is a problematic idea, as not always a clean root-environment is prepared and permission and ownership mixture between real and effective user can happen. In worst cases session login is blocked .
Example: running "sudo geany", will make geany save settings within users-geany settings, and will change permissions and ownership of those settings files to root, in addition to security and .Xauthority related permission hicups.
This is due to a very stupid bug that was introduced a year or two ago and IIUC has since been fixed. We routinely tell people to start X applications with sudo when they are trying to repair a system. As long as the bug gets fixed then I think this should be safe again.

MX and antiX were designed for users to be able to use sudo in this way. We also add /sbin/ and /usr/sbin/ to the user's PATH so they can more easily use sudo to launch programs in those directories. If there are reasons besides the stupid bug that make you think we should eschew using sudo then let's discuss that elsewhere. We have been relying on this use of sudo for many years.
Will I cry when it's all over?
When I die will I see Heaven?

Post Reply

Return to “MX Help”