From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B3B93158020 for ; Wed, 26 Oct 2022 16:53:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 26550E0970; Wed, 26 Oct 2022 16:53:28 +0000 (UTC) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00:e000:1e9::8849]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CBAD1E0969 for ; Wed, 26 Oct 2022 16:53:27 +0000 (UTC) Received: from Contact-TNet-Consulting-Abuse-for-assistance by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id 29QGrQKM003870 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 26 Oct 2022 11:53:26 -0500 Subject: Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!! To: gentoo-user@lists.gentoo.org References: From: Grant Taylor Organization: TNet Consulting Message-ID: Date: Wed, 26 Oct 2022 10:52:29 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: b531b214-8dbd-4582-a613-30309b90b756 X-Archives-Hash: d27845075e7e8325f6846762160b6f37 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