Re: [gentoo-user] Re: Update to /etc/sudoers disables wheel users!!!
Ramon Fischer wrote: > Do you also use "vim" from time to time? > > Because it is also able to compare two (or more?) files, similiar to > "sdiff": > > $ vi -d file1 file2 > > or: > > $ vi file1 > :diffthis > :vsplit > CTRL+w + right arrow key > :e file2 > :diffthis > > -Ramon > > On 27/10/2022 00:44, Dale wrote: >> I'd like a GUI tool where I can >> click the one I want to keep with my rodent and then save. > I'd only use vi stuff if I had a gun pointed at me. Even then, I'd make a mess of it. lol Dale :-) :-)
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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.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. -- GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF OpenPGP_0x155BE26413E699BF.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] Re: Update to /etc/sudoers disables wheel users!!!
Do you also use "vim" from time to time? Because it is also able to compare two (or more?) files, similiar to "sdiff": $ vi -d file1 file2 or: $ vi file1 :diffthis :vsplit CTRL+w + right arrow key :e file2 :diffthis -Ramon On 27/10/2022 00:44, Dale wrote: I'd like a GUI tool where I can click the one I want to keep with my rodent and then save. -- GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF OpenPGP_0x155BE26413E699BF.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] [SOLVED] rsync local mirror question
On Wed, Oct 26, 2022 at 05:42:24PM +0100, Michael wrote > On Wednesday, 26 October 2022 16:48:29 BST Walter Dnes wrote: > > * In https://wiki.gentoo.org/wiki/Local_Mirror the file to change is > > given as /etc/portage/repos.conf/gentoo-mirror.conf There is no such > > file on my system. Should I file a documentation bug? > > Yes, I think it should be updated. Problem; "https://bugs.gentoo.org/enter_bug.cgi; specifically says "Documentation: Documentation other than Wiki and translations." The documentation problem is on the wiki page. Now what? -- 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.
Re: [gentoo-user] Re: Update to /etc/sudoers disables wheel users!!!
On Wed, Oct 26, 2022 at 5:26 PM Grant Edwards wrote: > > On 2022-10-26, Dale wrote: > > 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 talking about? If > > so, name or what package has it? > > At one point, I had one of my systems configured to use "meld" when I > picked "interactive merge" in the etc-update menu, but I've since gone > back to just picking "show differences" in the etc-update menu, then > manually running merge on the two filenames shown. With the > interactive merge option, I was always a bit confused about which file > was the destination and what happened after I exited meld. > I use cfg-update+meld. It can use any 3-way diff/edit tool, but there aren't many of those. I believe the three panels show: Left: the current config file Right: new new packaged config file Center: what the packaged config file was the last time you did an update So Left vs Center shows you what changes you've made vs upstream, and center vs right show you what changes upstream made to their file. So you would look for differences on the right side to see what needs attention in the file, and then work those changes if appropriate into the left file. You just edit the left file to get it the way you want it and save that, and then cfg-update captures the changes in RCS. -- Rich
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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
Re: [gentoo-user] Re: Update to /etc/sudoers disables wheel users!!!
Grant Edwards wrote: > On 2022-10-26, Dale wrote: >> 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 talking about? If >> so, name or what package has it? > At one point, I had one of my systems configured to use "meld" when I > picked "interactive merge" in the etc-update menu, but I've since gone > back to just picking "show differences" in the etc-update menu, then > manually running merge on the two filenames shown. With the > interactive merge option, I was always a bit confused about which file > was the destination and what happened after I exited meld. > > -- > Grant I've tried etc-update and dispatch-conf and I can't figure out either one of them when it comes to merging. I'd like a GUI tool where I can click the one I want to keep with my rodent and then save. Like you, I get confused trying to select things and then have no idea if I'm about to royally screw something up. I end up doing a ctrl c, restarting update tool and zapping the new file and praying that didn't break anything either. I have the default settings so there may be a better way but I just don't know what. I sometimes wish there was a video showing different methods of managing config files and me picking what makes sense to me. I might add, a good while back I started doing updates in a chroot and then using -k on my main system. Since then, I don't see config updates hardly at all. I wonder if building in a chroot affects that. Dale :-) :-)
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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 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. -- GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF OpenPGP_0x155BE26413E699BF.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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 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 chroot. -- GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF OpenPGP_0x155BE26413E699BF.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[gentoo-user] Re: Update to /etc/sudoers disables wheel users!!!
On 2022-10-26, Dale wrote: > 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 talking about? If > so, name or what package has it? At one point, I had one of my systems configured to use "meld" when I picked "interactive merge" in the etc-update menu, but I've since gone back to just picking "show differences" in the etc-update menu, then manually running merge on the two filenames shown. With the interactive merge option, I was always a bit confused about which file was the destination and what happened after I exited meld. -- Grant
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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) pgpsN2HbVhyI1.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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 talking about? If so, name or what package has it? Thanks. Dale :-) :-)
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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. pgpD5GUPcUQVi.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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 chroot. -- Neil Bothwick Facts are stubborn, but statistics are more pliable pgpcq6_EGs3CW.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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 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
Re: [gentoo-user] Re: repair of a seg-faulting bin-utils
On Wed, 2022-10-26 at 14:37 -0400, Rich Freeman wrote: > Another possible issue is bad -march settings. That usually is an > issue if you change your CPU and boot off of an existing hard drive. > If you're going to upgrade your CPU you should rebuild all of @system > (at least) with -march set to something very minimal. Don't assume > that a newer CPU does everything an existing one does - they sometimes > do drop instructions. You can set -mcpu to whatever you want, as a > bad -mcpu will only cause minor performance issues. Further reading on this: https://wiki.gentoo.org/wiki/Safe_CFLAGS I've always used this as a reference for helping ensure make.conf is not only going to be well optimized, but produce reliable binaries.
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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 command line? -- GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF OpenPGP_0x155BE26413E699BF.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] Re: repair of a seg-faulting bin-utils
On Wed, Oct 26, 2022 at 12:24 PM Grant Edwards wrote: > > On 2022-10-26, Corbin wrote: > > Help! > > > > The last update I did built/installed bin-uitls. It is now producing > > seg-faults. I forgot to make a quickpkg of the old bin-utils before > > upgrading. > > The first thing I would do is run a RAM test overnight. IME, > segfaulting binutils or gcc has usually been a hardware problem. Bad disk is obviously another possible issue (saw that on a pi sdcard), but I'd definitely be testing that RAM. Really if you suspect bad RAM it is worth your trouble to just shut down ASAP and test that, because every minute with bad RAM is potentially corrupted files on your hard drive, and rework even if you have a good backup. Another possible issue is bad -march settings. That usually is an issue if you change your CPU and boot off of an existing hard drive. If you're going to upgrade your CPU you should rebuild all of @system (at least) with -march set to something very minimal. Don't assume that a newer CPU does everything an existing one does - they sometimes do drop instructions. You can set -mcpu to whatever you want, as a bad -mcpu will only cause minor performance issues. -- Rich
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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/zz ALL ALL=(ALL) !ALL }:-) -- GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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/zz > > > > 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! pgpkft0Ndewt6.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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/00-wheel # negate the entry !wheel ALL=(ALL) ALL $ sudo --list User ramon may run the following commands on : Entry is gone -Ramon On 26/10/2022 18:52, Grant Taylor wrote: 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. -- GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF OpenPGP_0x155BE26413E699BF.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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 -Ramon On 26/10/2022 18:52, Grant Taylor wrote: What if someone were to put the following into /etc/sudoers.d/zz ALL ALL=(ALL) !ALL }:-) -- GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF OpenPGP_0x155BE26413E699BF.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-user] Re: Update to /etc/sudoers disables wheel users!!!
Of course, you are free to do so, but then blindly overwriting default configuration files is a Layer 8 problem. -Ramon On 26/10/2022 19:12, Grant Edwards wrote: On 2022-10-26, Grant Taylor wrote: To the sudo developers, the /etc/sudoers file is *SUPPOSED* *TO* /be/ /edited/. And editing that file is how I configure sudo. And when an emerge update changes /etc/sudoers, the edited file is left as-is and there is a message that you need to run etc-update to merge the changes. -- Grant -- GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF OpenPGP_0x155BE26413E699BF.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[gentoo-user] Re: gio/pcmanfm sftp:// "operation not supported"
On 2022-10-26, Grant Edwards wrote: > The problem wasn't that the daemon was missing. There is a DBUS > daemon, and other things that use DBUS (e.g. notifications) work fine. > > What was apparently missing was a "session" > > $ set | grep dbus (same result with "grep DBUS") > $ dbus-launch bash > > $ set | grep DBUS > > DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-45cBmpKpTX,guid=b783eda6500beba7132e450b63596c64 Where is one supposed to strat a DBUS session? Should ssh logins have one? Should each X session have one? Should each console login have one? Should every bash instance have one?
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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 > > 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
[gentoo-user] Re: gio/pcmanfm sftp:// "operation not supported"
On 2022-10-26, Matt Connell wrote: > On Wed, 2022-10-26 at 16:22 +, Grant Edwards wrote: >> Apparently, that error is cause by lack of a DBUS session. I just >> happened to stumble across a posting somewhere by somebody who had the >> same problem. How they figured out that was the problem remains a >> mystery. > > It is likely that nobody else noticed this because dbus has moved into > that "it is assumed to be there" tier of daemons these days. The problem wasn't that the daemon was missing. There is a DBUS daemon, and other things that use DBUS (e.g. notifications) work fine. What was apparently missing was a "session" $ set | grep dbus $ dbus-launch bash $ set | grep DBUS DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-45cBmpKpTX,guid=b783eda6500beba7132e450b63596c64 > Like most GNOME components, the GNOME developers are assuming all of > GNOME is available all of the time. Yep. -- Grant
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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 pgpiZnySyaoNJ.pgp Description: OpenPGP digital signature
[gentoo-user] Re: Update to /etc/sudoers disables wheel users!!!
On 2022-10-26, Grant Taylor wrote: > To the sudo developers, the /etc/sudoers file is *SUPPOSED* *TO* /be/ > /edited/. And editing that file is how I configure sudo. And when an emerge update changes /etc/sudoers, the edited file is left as-is and there is a message that you need to run etc-update to merge the changes. -- Grant
Re: [gentoo-user] Help with dracut, please
On Wed, 26 Oct 2022 15:22:42 +0100, Peter Humphrey wrote: > On booting the new system I get an error I haven't heard of before: > dracut complaining "sysroot has no proper sysfs layout". I'm sure I've > done something stupid, but where do I start debugging this? Google > hasn't helped. Is CONFIG_SYSFS=y set in your kernel? -- Neil Bothwick Bumper Sticker: If you can read this, you are in phaser range. pgpEvfyRivY2v.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: gio/pcmanfm sftp:// "operation not supported"
On Wed, 2022-10-26 at 16:22 +, Grant Edwards wrote: > Apparently, that error is cause by lack of a DBUS session. I just > happened to stumble across a posting somewhere by somebody who had the > same problem. How they figured out that was the problem remains a > mystery. It is likely that nobody else noticed this because dbus has moved into that "it is assumed to be there" tier of daemons these days. Like most GNOME components, the GNOME developers are assuming all of GNOME is available all of the time.
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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/zz 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
Re: [gentoo-user] [SOLVED] rsync local mirror question
On Wednesday, 26 October 2022 16:48:29 BST Walter Dnes wrote: > On Tue, Oct 25, 2022 at 11:07:14PM +0100, Michael wrote > > > No, you shouldn't have to do any such thing. Just make sure you > > have set up in your '/etc/portage/repos.conf/gentoo.conf' the correct > > > rsync mirror and commented out the server on the Internet; e.g.: > OK, I tried it on my other used Lenovo laptop (thimk2) and it works. > But "inquiring minds want to know"... > > * In your instructions '/etc/portage/repos.conf/gentoo.conf' is the file > to change sync-uri in (and it works). > > * In https://wiki.gentoo.org/wiki/Local_Mirror the file to change is > given as /etc/portage/repos.conf/gentoo-mirror.conf There is no such > file on my system. Should I file a documentation bug? Yes, I think it should be updated. This wiki page states what's currently the convention: https://wiki.gentoo.org/wiki/Handbook:AMD64/Portage/ Files#Gentoo_ebuild_repository However, *.conf files can be nested and portage will parse them all the same. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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 ".
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 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
[gentoo-user] Re: repair of a seg-faulting bin-utils
On 2022-10-26, Corbin wrote: > Help! > > The last update I did built/installed bin-uitls. It is now producing > seg-faults. I forgot to make a quickpkg of the old bin-utils before > upgrading. The first thing I would do is run a RAM test overnight. IME, segfaulting binutils or gcc has usually been a hardware problem. -- Grant
[gentoo-user] Re: gio/pcmanfm sftp:// "operation not supported"
On 2022-10-26, Matt Connell wrote: > On Tue, 2022-10-25 at 21:31 +, Grant Edwards wrote: >> Google led me to several pages where the problem was not having gvfs >> installed. I do have gvfs installed, but I suspect it's broken. I get >> the impression that >> >> $ gio list sftp:/// >> >> is supposed to work, but that too says "Operation not supported". Apparently, that error is cause by lack of a DBUS session. I just happened to stumble across a posting somewhere by somebody who had the same problem. How they figured out that was the problem remains a mystery. [Is there a GNOME development group dedicated to making error messages as meaningless as possible? If yes, then they're doing a stellar job.] > I don't use pcmanfm, but I do have gvfs installed. Trying to "gio list > sftp://host; returns "The specified location is not mounted", so at > least my behavior is different. After launching a dbus session with $ dbus-launch bash And then running 'gio list' in the bash instance that is created above, I get the "location is not mounted error" A subsequent gio mount command then succeeds $ gio mount sftp:/// After which the "gio list" command works as expected. When I run pcmanfm-qt from that same bash instance, sftp URLs work. GNOME: making life overly complicated since 1999! -- Grant
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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
[gentoo-user] repair of a seg-faulting bin-utils
Help! The last update I did built/installed bin-uitls. It is now producing seg-faults. I forgot to make a quickpkg of the old bin-utils before upgrading. Added problem, dead optical drive. No cdrom/dvd or bluray. How can I fix this without having to reinstall from scratch?
Re: [gentoo-user] Help with dracut, please
On Wednesday, 26 October 2022 16:47:46 BST Dale wrote: > Peter Humphrey wrote: > > Hello list, > > > > I'm installing Gentoo on a new Juno laptop, and I've reached the point of > > booting into the new system. I have a separate /usr partition and I'm > > using > > dracut to create an initramfs. > > > > On booting the new system I get an error I haven't heard of before: dracut > > complaining "sysroot has no proper sysfs layout". I'm sure I've done > > something stupid, but where do I start debugging this? Google hasn't > > helped. > I tried to google that message and it found nothing. That's not good. > Makes me wonder what is causing that. Made me think a bit. > > Have you double checked your fstab? Maybe you missed updating a line, > missed commenting something out or a typo maybe? Any strange kernel > options added to your bootloader? Typo maybe? Have you double checked > that the file systems you use for /boot and / are built into the kernel? ^^This^^ Otherwise it may be some corrupt fs, in which case fsck could help. signature.asc Description: This is a digitally signed message part.
[gentoo-user] [SOLVED] rsync local mirror question
On Tue, Oct 25, 2022 at 11:07:14PM +0100, Michael wrote > > No, you shouldn't have to do any such thing. Just make sure you > have set up in your '/etc/portage/repos.conf/gentoo.conf' the correct > rsync mirror and commented out the server on the Internet; e.g.: OK, I tried it on my other used Lenovo laptop (thimk2) and it works. But "inquiring minds want to know"... * In your instructions '/etc/portage/repos.conf/gentoo.conf' is the file to change sync-uri in (and it works). * In https://wiki.gentoo.org/wiki/Local_Mirror the file to change is given as /etc/portage/repos.conf/gentoo-mirror.conf There is no such file on my system. Should I file a documentation 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.
Re: [gentoo-user] Help with dracut, please
Peter Humphrey wrote: > Hello list, > > I'm installing Gentoo on a new Juno laptop, and I've reached the point of > booting into the new system. I have a separate /usr partition and I'm using > dracut to create an initramfs. > > On booting the new system I get an error I haven't heard of before: dracut > complaining "sysroot has no proper sysfs layout". I'm sure I've done > something > stupid, but where do I start debugging this? Google hasn't helped. > I tried to google that message and it found nothing. That's not good. Makes me wonder what is causing that. Made me think a bit. Have you double checked your fstab? Maybe you missed updating a line, missed commenting something out or a typo maybe? Any strange kernel options added to your bootloader? Typo maybe? Have you double checked that the file systems you use for /boot and / are built into the kernel? Hopefully someone else will have more ideas but in the meantime, may want to double check those. Just to be sure. Hope that helps, or someone else has ideas. Dale :-) :-)
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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 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). -- GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF OpenPGP_0x155BE26413E699BF.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[gentoo-user] Help with dracut, please
Hello list, I'm installing Gentoo on a new Juno laptop, and I've reached the point of booting into the new system. I have a separate /usr partition and I'm using dracut to create an initramfs. On booting the new system I get an error I haven't heard of before: dracut complaining "sysroot has no proper sysfs layout". I'm sure I've done something stupid, but where do I start debugging this? Google hasn't helped. -- Regards, Peter.
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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 > 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
Re: [gentoo-user] rsync local mirror question
On Wednesday, 26 October 2022 03:06:19 BST Walter Dnes wrote: > On Tue, Oct 25, 2022 at 11:07:14PM +0100, Michael wrote > > > sync-type = rsync > > #sync-uri = rsync://rsync.gentoo.org/gentoo-portage > > sync-uri = rsync://192.168.1.252/gentoo-portage > > Thanks Michael (and Adam). I did indeed forget to update sync-uri. > I subscribe to Netflix, which requires Google-Chrome. It nags for > security updates every few days, so I'll soon find out how well the > corrected mirror setup works. > > Question: Can I leave "GENTOO_MIRRORS" uncommented in make.conf? The > minimal change for my laptop would be... Yes, you may leave your GENTOO_MIRRORS URIs as you have it, unless you don't want to be downloading the same source files more than once for machines in your LAN. If downloading chrome source files many times a week separately for multiple machines is no fun, you can set up a local http proxy caching server with its webroot pointing to its distfiles directory. Then in your clients' GENTOO_MIRRORS directive add as the first mirror your LAN Gentoo address/port. The only drawback is you will have to sync and then emerge --fetchonly, or -- fetch-all-uri, on the local mirror before you start emerging the various client PCs. A cron job can ensure this is all done by the time you're ready to run sync & emerge on the rest of your clients. You can use any number of available webservers with small footprint; e.g. nginx, lighttpd, boa, etc. The http-replicator is no longer available. > ...when at home on my LAN... > > #sync-uri = rsync://rsync.gentoo.org/gentoo-portage > sync-uri = rsync://192.168.1.252/gentoo-portage > > ...when taking the laptop out of my apartment... > > sync-uri = rsync://rsync.gentoo.org/gentoo-portage > #sync-uri = rsync://192.168.1.252/gentoo-portage I don't know if you can set more than one sync server, so if the first is not available it will try the next and so on. When the sync URI was defined in make.conf this was the case. I suppose you can try it. If it works it'll save you having to manually edit the file each time you move your laptop away from your LAN. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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 your clock again.
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.
I go with the more locked down approach
This is the best way. Try to be as precise as possible, but be aware of
wildcards![1]
-Ramon
[1]
https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-4-wildcards/
On 26/10/2022 08:31, Walter Dnes wrote:
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 ". A more locked
down approach allows regular users to run "sudo ".
This guards against "fat-finger-syndrome". I go with the more locked
down approach
--
GPG public key: 5983 98DA 5F4D A464 38FD CF87 155B E264 13E6 99BF
OpenPGP_0x155BE26413E699BF.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!
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 ". A more locked
down approach allows regular users to run "sudo ".
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.
