I had the following in my /etc/sudoers before tonight's update...

## Uncomment to allow members of group wheel to execute any command
%wheel ALL=(ALL:ALL) ALL

## Same thing without a password
%wheel ALL=(ALL:ALL) NOPASSWD: ALL

...and my regular user was able to run commands and scripts via
/usr/bin/sudo which had been authorized in files in the /etc/sudoers.d directory. Tonight's update changed /etc/sudoers to...

## Uncomment to allow members of group wheel to execute any command
# %wheel ALL=(ALL:ALL) ALL

## Same thing without a password
# %wheel ALL=(ALL:ALL) NOPASSWD: ALL

I was "like WTF?!?" but I let it through. sudo stopped working for my regular user. As root, I went in and manually reverted the update with
visudo. Is this a bug?

--
I've seen things, you people wouldn't believe; Gopher, Netscape with
frames, the first Browser Wars. Searching for pages with AltaVista,
pop-up windows self-replicating, trying to uninstall RealPlayer. All
those moments, will be lost in time like tears in rain... time to die.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 2022-10-25 at 22:34 -0400, Walter Dnes wrote:

 Is this a bug?

Nope, this is the way it is supposed to work.

Ramon is correct, user changes should go into sudoers.d which has been
the case for... some years now, I think? I don't recall.

I still make changes in sudoers directly, and just make sure dispatch-
conf doesn't squish them. I like to live dangerously I guess.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 2022-10-25 at 21:15 -0600, Grant Taylor wrote:

I *STRONGLY* /OBJECT/ to the notion that users should not edit
configuration files.

Calm down. Nobody said you can't. I do. Just know what you're doing
and pay attention to what portage does with package-managed
configuration files.

dispatch-conf even gives you the opportunity to edit it before
applying.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/25/22 9:04 PM, Ramon Fischer wrote:

I do not think, that this is a bug, since it is the default file, which should not be edited by the user.

I *STRONGLY* /OBJECT/ to the notion that users should not edit
configuration files.

By design, that's the very purpose of the configuration file, for users
to edit them to be what they want them to be.

The concept of "don't edit configuration files" seems diametrically
opposed to the idea of Gentoo as I understand it. Namely, /you/ build
/your/ system to behave the way that /you/ want it to.

All changes should be done in "/etc/sudoers.d/" to avoid such cases.

Then why in the world does the /default/ file, as installed by Gentoo,
include directions to edit the the file?!?!?!

Aside: Someone recently posted a comment to the sudo users mailing list
(exact name escapes me) wherein their security policy prohibited
@includedir explicitly because of the capability that adding a file to
such included directories inherently enabled sudo access -or- caused
sudo to fail secure and perform a Denial of Service. They were required
to use individual @include directives.

IMHO telling a Gentoo user not to modify a file in /etc takes hutzpah.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

# emerge app-admin/doas
# emerge -c app-admin/sudo
# ln -s ./doas /usr/bin/sudo

:P

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Oct 26, 2022 at 05:04:35AM +0200, Ramon Fischer wrote

Hello Walter,

I do not think, that this is a bug, since it is the default file, which should not be edited by the user.

Firstly "grep -i uncomment /etc/sudoers" results in...

## Uncomment to enable special input methods. Care should be taken as
## Uncomment to use a hard-coded PATH instead of the user's to find commands
## Uncomment to send mail if the user does not enter the correct password.
## Uncomment to enable logging of a command's output, except for
## Uncomment to allow members of group wheel to execute any command
## Uncomment to allow members of group sudo to execute any command
## Uncomment to allow any user to run sudo if they know the password

...I.e. the file is explicitly telling you to edit it if required!!!

All changes should be done in "/etc/sudoers.d/" to avoid such cases.

My regular user has script "settime" in ${HOME}/bin

#!/bin/bash
date
/usr/bin/sudo /usr/bin/rdate -nsv ca.pool.ntp.org
/usr/bin/sudo /sbin/hwclock --systohc
date

/etc/sudoers.d/001 has, amongst other things, two lines...

waltdnes x8940 = (root) NOPASSWD: /sbin/hwclock --systohc
waltdnes x8940 = (root) NOPASSWD: /usr/bin/rdate -nsv ca.pool.ntp.org

User "waltdnes" is a member of "wheel". If the "wheel" line is
uncommented in /etc/sudoers, sudo works for me. If the "wheel" line is commented, then sudo breaks for my regular user.

I kept mine unchanged from 2nd October and only have two uncommented lines:

    [...]
    root ALL=(ALL:AlL) ALL
    [...]
    @includedir /etc/sudoers.d

I am using version "1.9.11_p3-r1".

Me too.

There seem to be two different approaches here. The loose approach is
to allow a user to run "sudo <whatever I damn well want>". A more locked
down approach allows regular users to run "sudo <very specific command>".
This guards against "fat-finger-syndrome". I go with the more locked
down approach

--
I've seen things, you people wouldn't believe; Gopher, Netscape with
frames, the first Browser Wars. Searching for pages with AltaVista,
pop-up windows self-replicating, trying to uninstall RealPlayer. All
those moments, will be lost in time like tears in rain... time to die.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Oct 26, 2022 at 3:42 AM Ramon Fischer <Ramon_Fischer@hotmail.de> wrote:

I do not know, what the developers were thinking to encourage the user
to edit a default file, which gets potentially overwritten after each
package update...

"etc-update" helps to have an eye on, but muscle memory and fast fingers
are sometimes faster.

The Gentoo preference tends to be to follow upstream. So if sudo
upstream distributes a file like this that has comments encouraging
users to edit it, then that is likely how Gentoo will ship it. If
sudo switched to moving everything into an include-based system
UPSTREAM then Gentoo would probably start shipping that. If you look
at the sudo ebuild you'll see that the config files are 100% upstream.

If you look at things like systemd units or udev rules they're much
more include-oriented, as this is the upstream preference.

Gentoo has emphasized using config file protection early on, and
doesn't have any official preference for using included config
directories distro-wide. Portage has been moving in this direction
for a while though (for the stuff in /etc/portage).

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/25/22 9:44 PM, Matt Connell wrote:

Calm down.

I am calm.

The suggestion to not edit the (/etc/sudoeres) configuration file is one
of those types of things that if nobody objects to then eventually not
doing so will become defacto policy. So I objected, calmly, but with
emphasis.

Nobody said you can't.

Yet. (See above.)

I do.

I do too.

Just know what you're doing and pay attention to what portage does
with package-managed configuration files.

Yep.

This is a common pitfall across multiple distributions / operating
systems / platforms.

dispatch-conf even gives you the opportunity to edit it before
applying.

Yep.

I almost always reject the changes suggested on config files that I've
modified and accept them on files that I've not modified.

I really do wish that there was a better way to manage this, likely
involving diffs / deltas. E.g. what changed between the N distribution
file and the N+1 distribution file. Can that same change be safely
applied to the N' distribution file to create the N'+1 file?



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/26/22 1:42 AM, Ramon Fischer wrote:

and your user is able to synchronise your clock again.

I'm not sure that will work as hoped. See my other reply about PTY and
testing the commands at the command line for more explanation of what I
suspect is happening.

I do not know, what the developers were thinking to encourage the user
to edit a default file, which gets potentially overwritten after each
package update...

To the sudo developers, the /etc/sudoers file is *SUPPOSED* *TO* /be/
/edited/.

The sudo developers provide the sudo (et al.) program(s) for your use
and /you/ provide the configuration file(s) that it (they) use.

It is natural for the /etc/sudoers file to be edited.

To me the disconnect is when people other than the sudo developers
distribute the /etc/sudoers file and expect that it will not be edited.

What are end users / systems administrators to do if the default file
has something like the following enabled in the default /etc/sudoers
file and the EUs / SAs want it to not be there?

%wheel ALL=(ALL:ALL) ALL

They have no choice but to change (edit / replace) the /etc/sudoers file.

Especially if other parts of the system rely on the wheel group and not
putting users in it is not an option. -- The above line *MUST* be
taken out, thus the /etc/sudoers file *MUST* be edited.

Unix has 50 years of editing files to make the system behave as desired.
Modularization and including other files is nice /when/ /it/ /works/.
But there are times that modularization doesn't work and files *MUST* be edited.

"etc-update" helps to have an eye on, but muscle memory and fast fingers
are sometimes faster.

How many levels of safety do you suggest that we put in place?

What if someone were to put the following into /etc/sudoers.d/zzzzzzzzzz

ALL ALL=(ALL) !ALL

}:-)

This is the best way. Try to be as precise as possible, but be aware of wildcards![1]

The /etc/sudoers syntax can be tricky to master. But it can also be
very powerful when done correctly.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/26/22 12:31 AM, Walter Dnes wrote:

My regular user has script "settime" in ${HOME}/bin

#!/bin/bash
date
/usr/bin/sudo /usr/bin/rdate -nsv ca.pool.ntp.org
/usr/bin/sudo /sbin/hwclock --systohc
date

/etc/sudoers.d/001 has, amongst other things, two lines...

waltdnes x8940 = (root) NOPASSWD: /sbin/hwclock --systohc
waltdnes x8940 = (root) NOPASSWD: /usr/bin/rdate -nsv ca.pool.ntp.org

User "waltdnes" is a member of "wheel". If the "wheel" line is
uncommented in /etc/sudoers, sudo works for me. If the "wheel"
line is commented, then sudo breaks for my regular user.

Please try running the two sudo lines from the script as is on the
command line as the waltdnes user. I'm wondering if the problem is
potentially related to something else, namely sudo wanting to read from
a terminal (PTY) in some configurations.

I believe there is a non-zero chance that the commands allowed via the /etc/sudoers.d/001 file will work as entered. But that running sudo
from within a script, as opposed to on the command line, /may/ be the
source of problems. -- Divide and conquer the problem.

There seem to be two different approaches here. The loose approach
is to allow a user to run "sudo <whatever I damn well want>".

This seems to be -- what I refer to as -- the distribution default.
E.g. get people to run things through sudo vs running things through su
or running directly as root.

A more locked down approach allows regular users to run "sudo <very
specific command>".

This is -- what I refer to as -- the (more) enterprise approach. It
also seems to be the next evolution of the distribution default wherein
people want to start restricting what can and can't be run via sudo.

The enterprise approach also tends to come more into play as you use
sudo to run things as users other than root; e.g. run RDBMS commands as
the Oracle user or backup commands as the Tivoli user.

This guards against "fat-finger-syndrome".

I think it's more than protection against fat-finger-syndrome. After
all, unless the sudoers file(s) is (are) *EXTREMELY* specific down to
and including command parameters / options, you can still fat-finger
command parameters / options.

When you start separating duties and who is allowed to do what is when
you start to see the more locked down enterprise methodology.

I go with the more locked down approach

I use the distribution default on my personal systems where I'm 95% of
the use case.

I use the enterprise method on work systems where we have multiple
people with different skill levels doing different tasks.

Aside: One advantage of the enterprise method is that you can allow a
command as one target user (Oracle) but not the (default) root user.
Thus helping protect against people omitting a critical option. --
Many things, e.g. Oracle RDBMS, get rather upset when commands
(accidentally) change the ownership of files when run as the wrong user.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 26 Oct 2022 10:21:06 -0600, Grant Taylor wrote:

dispatch-conf even gives you the opportunity to edit it before
applying.

Yep.

I almost always reject the changes suggested on config files that I've modified and accept them on files that I've not modified.

I really do wish that there was a better way to manage this, likely involving diffs / deltas. E.g. what changed between the N distribution
file and the N+1 distribution file. Can that same change be safely
applied to the N' distribution file to create the N'+1 file?

conf-update allows you to merge the new and old files, prompting you to
pick which to use on each differing section, with a further option to
edit the lines. That way you can keep your changed lines but still add
lines relating to new config options.


--
Neil Bothwick

Top Oxymorons Number 36: Alone together

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE8k9T/rX16EJxEKG692eFu0QSMJgFAmNZaygACgkQ92eFu0QS MJg5Dw/7BAkS5OqQhNmb3WDj5os330LsFwMosocio1Roqs6groeTnW2sDP2biqX/ lrG+7/RCm1obyRoX3i0ljrfa4IYOohoaItaRuyR7Y6lvSzGDMbVFqOXhJA26o7U+ 9VAPpoh2PxnMVeF13D5JUfiYPZQVRbeN3rNmq+lyChX+LzmS3iuKkOk3oln3AxK7 PmF4uPrXAeAyIuPvQ1PJ2mcraSTSM6Thdk3iPtc6vmVxpCPHzu0Diz/p6BvqVcue GzwLMthw0AKf8JdilzTXfWxoFBzJ+6rxZJp1vRjs00Ao0npQ9gjg0J5SckrgbWBp mG5fVo+teTw4Ag8AA79CIWeHRr2XErL6U+nl9gGAHBv1zn+GLga+kqDnYtgFlSyq DQvdGPjuU+P7r7CyWMDsJF5HC/dwvCGHMwUmRMKYYzO08HnO9xfAs538ggK8R7/H lxdviAga8w/M68D/NxHaz0LUapoTZ+5SZ+/C7/iDaJ8jV9E/jItj4inbMQWPSHmP sLqNSAM0svHx4DuoeL5cYP0YJzfxHf6y7XamKVfYT81Rfd7mCnr4o1cDN3kLMGIh 413zmIzzfz6+ArotSTT3ORtorxNQXfvZkwu9dMI8LlKrPbxsqv+Ndd72AKQCM9Xn V+2CvdcAiomEYh4qKOQ6uzauxs4XG74r4ImVEF3CA9W7tG/ZZVs=
=TTAn
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Oct 26, 2022 at 1:15 PM Neil Bothwick <neil@digimed.co.uk> wrote:

On Wed, 26 Oct 2022 10:21:06 -0600, Grant Taylor wrote:

dispatch-conf even gives you the opportunity to edit it before
applying.

Yep.

I almost always reject the changes suggested on config files that I've modified and accept them on files that I've not modified.

I really do wish that there was a better way to manage this, likely involving diffs / deltas. E.g. what changed between the N distribution file and the N+1 distribution file. Can that same change be safely
applied to the N' distribution file to create the N'+1 file?

conf-update allows you to merge the new and old files, prompting you to
pick which to use on each differing section, with a further option to
edit the lines. That way you can keep your changed lines but still add
lines relating to new config options.

It could really use an overhaul but cfg-update does 3-way diffs and
auto-merges based on them. Ie, if in a block of text you make a
change, and in a new update that particular block of text hasn't
changed, then your previous change will get auto-merged. If the
upstream file changed in that block of text then you can do a 3-way
diff.

The tool is really old and barely maintained (I'm caretaking it but
don't really want to deal with that - patches welcome). It also uses
RCS to store the change history for 3-way merging and that could
probably be switched to git or something more modern. If you use an
x11-based merge tool then it will also refuse to attempt an automatic
merge if X11 isn't available. (Obviously you can't actually run the
manual merge if the tool uses X11 and that isn't available.)

Using it I find that maybe 95% of my config file changes involve no prompts.

Another useful tool is etckeeper which is basically just some
integrations for portage around maintaining /etc in git. You can of
course just do that manually but it will auto-commit changes if you
forget to do so before an update.

--
Rich

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022.10.26 14:04, Ramon Fischer wrote:

Also a very interesting question!

I just tested this with "visudo" and it does not intercept this.

If "su" is disabled, you are locked out and you are forced to enter
your system via a live USB stick and a "chroot" in order to edit "/etc/shadow" to set a root password via "mkpasswd" and enable "su".
Nice. :D

Could you not interrupt grup and append "single" or "init=/bin/bash"
to the kernel command line?

-Ramon

On 26/10/2022 18:52, Grant Taylor wrote:

What if someone were to put the following into
/etc/sudoers.d/zzzzzzzzzz

   ALL ALL=(ALL) !ALL

}:-)

--
GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 26 Oct 2022 20:04:10 +0200, Ramon Fischer wrote:

Also a very interesting question!

I just tested this with "visudo" and it does not intercept this.

If "su" is disabled, you are locked out and you are forced to enter
your system via a live USB stick and a "chroot" in order to edit "/etc/shadow" to set a root password via "mkpasswd" and enable "su".
Nice. :D

You need to be root to write to /etc/sudoers.d. If someone has that
access, you are already doomed!

-Ramon

On 26/10/2022 18:52, Grant Taylor wrote:

What if someone were to put the following into
/etc/sudoers.d/zzzzzzzzzz

   ALL ALL=(ALL) !ALL

}:-)

--
Neil Bothwick

I thought I saw the light at the end of the tunnel...
but it was just some sod with a torch bringing me more work!

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE8k9T/rX16EJxEKG692eFu0QSMJgFAmNZessACgkQ92eFu0QS MJhO8g/9FMYDoOWDmW3sIk9mZoSuuweyYBlFnOHx/q/Zx71Y7Ro1qNrCvS43H106 ODi5RcrvDvQ9v1o6daacUo65Tn00Kp3p2wrITDUi18XQcexgR+4Cg8k569P4D2/x DpBDXlKROavz5CylafcldiXl/VFP494r9AARaeOOvw4GEtLEW6HHleZqyyGBmCxc fAytx7uMV3AzLYM4VWFpXkjhBrVzTU+U2/PCsmAV/AW5MEBsmeBEMqXfRdOZAD9q Nwjl6hLSHt6m/ywSr0T2HLhzCeeQqxVEqQR2ldNM4WW53SUDo1B9TiKpTaj8Nqvr ddSy9DvVoyyXvirCvKZQbSaCIpEbpy1h2jCAVJqL4+IpbWhHF74W0hlwvbMM/mKc D33AdON8bjpqSJrDJYbfUC7UIyGfzrUdIz1LmsXt7ANfJZWiAqvwHvYKZ8jW5sBu guwsPG+OSPT43E250dEHbwzaFF1MFc7VJM6JYPrpI5GkkJJM+hrvWnwofLpwnalX GfzXKiRPrdQ0EEfLY6tGgvp1tUtOOXqPGEBWpeyCLZNf2tSI5pdPYNoHsXV9RnGK 8m+P8rPxVafbjcrORcjvnOxPo0hkhmwklir+X4/o2SlZQ0knIp/A9NomYAqWuT2E NMHwjT+zQGFygAx98+BdX/HlbChETOd1Ots3kpJ3IFzGhjoMqEc=
=8iu/
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Ori

On 10/26/22 12:22 PM, Neil Bothwick wrote:

You need to be root to write to /etc/sudoers.d. If someone has that
access, you are already doomed!

And what happens if someone uses the existing root-via-sudo access to
break sudo?

You loose root-via-sudo access.

Someone could become root, via sudo, edit the sudoers file without using visudo, introduce a syntax problem, thereby breaking sudo (fail secure).

You could easily do this to yourself if you don't follow best practices.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/26/22 12:04 PM, Ramon Fischer wrote:

Also a very interesting question!

}:-)

I just tested this with "visudo" and it does not intercept this.

Nor should it.

It's perfect legitimate sudoers syntax.

The location; /etc/sudoers.d/zzzzzzzzzz vs the end of /etc/sudoers
(proper), doesn't matter.

If "su" is disabled, you are locked out and you are forced to enter your system via a live USB stick and a "chroot" in order to edit
"/etc/shadow" to set a root password via "mkpasswd" and enable "su".

Which is one of the reasons that it's important to have (set) a known
root password.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/26/22 12:35 PM, Jack wrote:

Could you not interrupt  grup and append "single" or "init=/bin/bash" to
the kernel command line?

Maybe.

It will depend on how complex your configuration is.

I don't remember if Gentoo requires root's password when entering single
user mode or not. (I've not tested it in a long time.)

Invoking Bash (or any shell) as init may not work as desired if your
system configuration is complex and needs fancier things (modules /
network resources / etc) during normal init.

My 20 years worth of experience is to have a root password set so that
you can fix this more directly and more reliably.

Ideally, as soon as you learn that sudo is not working as desired, use
su -- using root's password -- and revert the recent sudo change.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 26 Oct 2022 13:28:49 -0600, Grant Taylor wrote:

You need to be root to write to /etc/sudoers.d. If someone has that
access, you are already doomed!

And what happens if someone uses the existing root-via-sudo access to
break sudo?

So they have root access, nothing has changed. How they get root access
is irrelevant, just that they have it.


--
Neil Bothwick

A positive attitude may not solve all your problems, but it will annoy
enough people to make it worth the effort.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE8k9T/rX16EJxEKG692eFu0QSMJgFAmNZk7cACgkQ92eFu0QS MJgu8xAAiFXogzrKRbqq0lSZnNnd55SFcNzK1RrrlqCm59ZO/1IUTQ5yaIlbL5m9 TjygQwdXlU4yBBdHnzXmcxa6jbDvyFXQ6thUJMfZnT6Fm4qWyhQ+7f1ZT/AeeIqj ncDITqQlIjAppSEBpMRideQOX8Q41p/PlOWwpN+cjdFd2nIIdZzm56ptw067Cgsf VXTuTEbcpBC71sk7ikjG6ozFHBJcRVpxqUNh2wcj7SYtVRZmip10a7a92gRy7CU6 DSTAuplUm1PH2xZoalFGqa1JvkAP3IgiAjkR4MYTna+H3zwm5tWo/1Vh44T8SqXS HlW46zrRZ3Q3pdMoBxf0Aqo3nfzzW6WBKmmbyQsYPwt69t7G3VQJZEbVkQF2rbiD rbLRNERjtvhVuybvS1SAnfVlgfzgOy2VSpW1fzW7x2WxJP08IEmsWbh6v9eqcQo5 chRR0m3YifU27dx45SxIJPG+HyNqEZci4GRQf4te6/IDRQwZW9nwOSfqeSaAS2wX WDZe0nLDwYM7JnK4rhmP4ZVlNejCidzsk+eEslLLkBcmb9LerZz6rNTucKIkfu3e Yw7vzkG4is6ApgdNezeSrNF4vqj3iW1zXwhtSPP2Tqhp7Ky28iA5Lqjr7ewrn+SN 6OW3KHa9/AtHq9DoRRxDm4vfkiWqqvDwTNUgVNRlwE+MxIpUBB4=
=ptBe
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Orig

On Wed, 26 Oct 2022 20:38:35 +0200, Ramon Fischer wrote:

I thought in a too complicated way.

Why not just remove the entry from "/etc/sudoers.d/zzzzzzz", while
being in a "chroot"?

Still too complicated. Just mount the root partition from a live USB and
delete the file. no need for a chroot.


--
Neil Bothwick

Facts are stubborn, but statistics are more pliable

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE8k9T/rX16EJxEKG692eFu0QSMJgFAmNZk1kACgkQ92eFu0QS MJg45BAAnrLJI+YHCqblnUVE7VaxxJoicfUlcQDiMy7FJS12TSGVXYFtLMDDdrbP Z3scTSZMM3kCYcfa+XbmJOhKYrYciEtnpkMy1lcCZv4GKzv9x3XdfGK9tWQJaAhu vNXjrPtKYlLg0VucRIRiCxLgSX4wohlsd04OIIgHBF/dMPsZcAiYWEnBt2KRZ1fg 3w+GdcmjziURmWk5/dxvMegUgETdSSoIfbv3l7c+TgNhuJ2a6hWReQXyQ+ne0kk8 nSnDlUJeyGJ+KMdbWq3Bm+0zKOYAJkqHdKd3JyKlsO6/VqCZ3JmS2vQQOYjYysqM PpNoVfN+DJ+LCt10qnFtV6GNFqecW1GNSAtT5DBkgUZ/Icb/xqdPscP8p8P7odQW VTyyU1uHnPo7etwj8rbm4ADoqSiFduZIO3/SLAowhv/AYpr36Q7uoNQM+484yASo STa6pYkDkdF1IiaUbg611qRvcFMrQX4GOX/i+JZCcbg/8GqwDuTcP6nePtS/cPjT rFRU4V3hyKm/HobbH6pUI/zPHmmdD+MCiQ8wVySvKlXeG+nYC45K497uP/RuJZYx BDPdTGdAtXNJirOXl9AvED6tNJeLVZxU7UKXbV+TYBcOytvCJ2slQVOcjPJrF63M emKJzRC89YaJ4FC/VYOJSEpRNaxRHpQVbj68aFlaVqkE9MIUjfA=
=NR/t
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/26/22 2:08 PM, Neil Bothwick wrote:

So they have root access, nothing has changed. How they get root
access is irrelevant, just that they have it.

No, how they get root access is not irrelevant.

If your only access to root is via sudo and you break sudo you no longer
have root access.

If you don't have root access through something other than sudo, you
can't fix your sudo (from your existing system).



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 26 Oct 2022 14:17:30 -0600, Grant Taylor wrote:

On 10/26/22 2:08 PM, Neil Bothwick wrote:

So they have root access, nothing has changed. How they get root
access is irrelevant, just that they have it.

No, how they get root access is not irrelevant.

If your only access to root is via sudo and you break sudo you no
longer have root access.

If you don't have root access through something other than sudo, you
can't fix your sudo (from your existing system).

They and you are different people. You are looking at it from the
perspective of a user accidentally locking themself out of the system, so
su is the best way to be able to fix it. I agree with you there. I was
looking at it from the perspective of a third party changing sudo right
without your consent. We were at cross purposes.


--
Neil Bothwick

"We can't solve problems by using the same kind of thinking we used when
we created them." (Albert Einstein)

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE8k9T/rX16EJxEKG692eFu0QSMJgFAmNZousACgkQ92eFu0QS MJh/zBAAt0ZYQYScrGfWR1TJI15k6CByFo/WKVJ2GZ6NtapE8+xmFlZ/CxwRCqcy 6GPhKulxgijUvA+4koaoH9HjyMYRLgW2MYYYQ7kJzXnUpmxJPkyAnOn5aFHLeL5L uQvq/yzp4loXnO94PItD3h8QXRbcJt1WAdxyv3bbfP76uXqVYoLoa0WWgz0IeUwW 6f6uPP6TMcwrfuNN35Li6SZZsKcdU1OZ0ENn5NOQuu6aC89iJqIy9uYHdya8Sr+a fBOjzIt1htm79iUXwxFN8OKetleGGiXh4oVbgwyrTcQSEy7vaHPmnBmYqgod6sfD dLFYSS0oFdHYiZD0lSQ6VQxvZL1BUxRluRgax8P83FH9szSQZLHbUWmEHrGKPKn1 iLPSaG6YoMSOrTcm3H7Gb8NAkrLmsLk+WcHlSa3bYacVt7mdsN5k2bkoahEH4J3w jPmOMdxeqA4p+BlchHjhOBVEDwbXpIJR4l4fUqd9o7VzelAvu0yeGYg1k+oq0NqX qSgC0Wze/7rBuRIfqkdAAq6JofBb0iUQI6vSIAbexNrVGL33Dl2q6nOxCcq9u3lO oTPTkAm5tzuUuQ+FEzRmwg12jNLXQsNIgR9rQ1l+ZSsffTAM5mWxynTgjvJUcVbc VUhoGlFzrcZJ0SlGKBvvP4MY6+Bbq6VcwbRmPNDiq4NfkLau0BA=
=+juK
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: f

On 10/26/22 3:13 PM, Neil Bothwick wrote:

They and you are different people. You are looking at it from the
perspective of a user accidentally locking themself out of the system,
so su is the best way to be able to fix it. I agree with you there. I
was looking at it from the perspective of a third party changing sudo
right without your consent. We were at cross purposes.

ACK

Thank you for clarifying.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/26/22 3:27 PM, Ramon Fischer wrote:

Why was I thinking of a chroot?

Maybe because of reading "grup/grub" a few e-mails before and thinking
of "grub-mkconfig"...

Or maybe because entering a chroot is such a prominent thing to do when
booting off of Gentoo media to do an installation that it's largely
habitual for some of us. ;-)



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/26/22 3:48 PM, Ramon Fischer wrote:

I have created an issue at their Git repository. Maybe there will be
solution for this:

   https://github.com/sudo-project/sudo/issues/190

I ... don't know where to begin.

There are so many ways that you can hurt yourself with syntactically
valid sudoers that it's not even funny.

You could allow list almost all commands, without using the special ALL
place holder and then remark critical commands and end up in a very
similar situation.

At some point we have to trust that Systems Administrators / Sudoers
editors know what they are doing and let them do so.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10/26/22 7:27 PM, Ramon Fischer wrote:

Sure, you cannot cover everything, but mitigating at least a little bit
would be OK or not? :)

I don't know. :-/

It's the proverbial problem of spam / virus filtering and a spam / virus
gets through the filters and someone saying "But it's your fault because
you are supposed to protect me!!!".

Sometimes there's advantages to saying "here's a gun, it's loaded, and
the safety is off. we suggest not pointing it at your foot. If you do
point it at your foot, don't pull the trigger." type thing.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)