Good point!
This is where a public license comes into play[1] to say "we take no
responsibility, if you f'ed yourself up".
Just to make sure, that you are not liable.
-Ramon
[1] https://github.com/sudo-project/sudo/blob/main/LICENSE.md
On 27/10/2022 03:47, Grant Taylor wrote:
On 10/26/22 7
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
Sure, you cannot cover everything, but mitigating at least a little bit
would be OK or not? :)
-Ramon
On 27/10/2022 01:06, Grant Taylor wrote:
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
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 s
I have created an issue at their Git repository. Maybe there will be
solution for this:
https://github.com/sudo-project/sudo/issues/190
-Ramon
On 26/10/2022 21:28, Grant Taylor wrote:
On 10/26/22 12:22 PM, Neil Bothwick wrote:
You need to be root to write to /etc/sudoers.d. If someone has
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 tha
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 th
Ah, of course!
Why was I thinking of a chroot?
Maybe because of reading "grup/grub" a few e-mails before and thinking
of "grub-mkconfig"...
-Ramon
On 26/10/2022 22:06, Neil Bothwick wrote:
On Wed, 26 Oct 2022 20:38:35 +0200, Ramon Fischer wrote:
I thought in a too complicated way.
Why no
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 acces
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.
Rich Freeman wrote:
> 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.)
>
>
I'd like to try a GUI based tool. Is that what you
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 cha
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/zzz", 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 chr
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 no
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 sud
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/zz vs the end of /etc/sudoers
(proper), doesn't m
Of course, that would be sufficient.
I thought in a too complicated way.
Why not just remove the entry from "/etc/sudoers.d/zzz", while being
in a "chroot"?
-Ramon
On 26/10/2022 20:35, Jack wrote:
Could you not interrupt grup and append "single" or "init=/bin/bash"
to the kernel comman
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
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
Indeed, an intersting question, which you actually already answered
yourself. I just tested it myself:
$ visudo -f /etc/sudoers.d/00-wheel
%wheel ALL=(ALL) ALL
$ sudo --list
User ramon may run the following commands on :
(ALL) ALL
$ sudo -f /etc/sudoers.d/0
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
On Wed, Oct 26, 2022 at 1:15 PM Neil Bothwick 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
> > mo
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 real
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 deve
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) NOPASSW
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.
N
Interesting! Thank you for your research!
After working 20 hours straight - uptime said so - I did not feel like
it to do deeper research myself. :)
-Ramon
On 26/10/2022 13:31, Rich Freeman wrote:
On Wed, Oct 26, 2022 at 3:42 AM Ramon Fischer wrote:
I do not know, what the developers were
On Wed, Oct 26, 2022 at 3:42 AM Ramon Fischer 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
>
User "waltdnes" is a member of "wheel". If the "wheel" line is
uncommented in /etc/sudoers, sudo works for me.
So you could create the file "/etc/sudoers.d/000" with the following
content:
%wheel ALL=(ALL:ALL) ALL
%wheel ALL=(ALL:ALL) NOPASSWD: ALL
and your user is able to synchronise
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. C
# emerge app-admin/doas
# emerge -c app-admin/sudo
# ln -s ./doas /usr/bin/sudo
:P
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.
d
Good question, which confused me as well, when I was looking into the file.
Maybe ask the package maintainer or the developers?
-Ramon
On 26/10/2022 05:34, Ramon Fischer wrote:
Then why in the world does the /default/ file, as installed by Gentoo,
include directions to edit the the file?!?!?!
Hello Grant,
generelly, I totally agree with you! Freedom of changing files
everywhere is what makes Gentoo a good, user-suited Linux distribution.
But changing *default files* comes with the risk, that a package update
will overwrite it.
Therefore "[...].d/" directories were "invented", wh
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
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 jus
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. All changes should be done in
"/etc/sudoers.d/" to avoid such cases.
I kept mine unchanged from 2nd October and only have two uncommented lines:
[...]
root ALL=(ALL
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
/us
38 matches
Mail list logo
