Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!

[Anna “CyberTailor”]

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

:P

Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!

[Matt Connell]

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.

Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!

[Ramon Fischer]

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?!?!?! 


--
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!!!

[Ramon Fischer]

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", where "d" is an 
abbreviation for "directory" as far as I remember. This is supposed to 
be the playground for users.


Of course including external files come with risks, but how do you want 
to balance usability and security? It is difficult to answer this for me 
as well.

-Ramon

On 26/10/2022 05:15, Grant Taylor wrote:

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.





--
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!!!

[Grant Taylor]

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

Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!

[Matt Connell]

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.

Re: [gentoo-user] Update to /etc/sudoers disables wheel users!!!

[Ramon Fischer]

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:AlL) ALL
    [...]
    @includedir /etc/sudoers.d

I am using version "1.9.11_p3-r1".

What version are you using?
-Ramon

Maybe you have edited the default file before?

On 26/10/2022 04:34, Walter Dnes wrote:

   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?



--
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] Update to /etc/sudoers disables wheel users!!!

[Walter Dnes]

  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.

Re: [gentoo-user] rsync local mirror question

[Walter Dnes]

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...

...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'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] gio/pcmanfm sftp:// "operation not supported"

[Matt Connell]

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".

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.  

(Disclaimer, I may not know what I am doing with gio/gvfs; it is pulled
in by thunar and evince on my system.)

I have gvfs built with the following use flags enabled: cdda, elogind,
gnome-keyring, policykit, udev, udisks

Not sure if any of this is helpful to you or not, but maybe it will
provide a clue.

Re: [gentoo-user] rsync local mirror question

[Michael]

On Tuesday, 25 October 2022 21:36:40 BST Walter Dnes wrote:
>   I followed https://wiki.gentoo.org/wiki/Local_Mirror instructions for
> doing a local rsync mirror.  I ran commented the rsync mirrors line in
> the client's make.conf and ran "emerge --sync".  The client still
> synced from a server on the internet.  Do I need to manually force
> rsync to go local, e.g...
> 
> [thimk][root][~] rsync 192.168.1.252::
> gentoo-portage  Gentoo ebuild repository

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.:

[snip ...]

sync-type = rsync
#sync-uri = rsync://rsync.gentoo.org/gentoo-portage
sync-uri = rsync://192.168.1.252/gentoo-portage



signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] rsync local mirror question

[Adam Carter]

On Wed, Oct 26, 2022 at 7:35 AM Walter Dnes  wrote:

>   I followed https://wiki.gentoo.org/wiki/Local_Mirror instructions for
> doing a local rsync mirror.  I ran commented the rsync mirrors line in
> the client's make.conf and ran "emerge --sync".  The client still
> synced from a server on the internet.  Do I need to manually force
> rsync to go local, e.g...
>
>
Maybe you missed this
"Now, make the other computers use the local rsync mirror instead of a
public one, by changing the *sync-uri* entry in the appropriate file in
/etc/portage/repos.conf/
."

[gentoo-user] gio/pcmanfm sftp:// "operation not supported"

[Grant Edwards]

Does anybody have any idea how to get pcmanfm to work with sftp?

I've found plenty of sources claiming it should work but all I ever
get when I try to open "sftp:///" is "operation not supported"
[same result for both pcmanfm and pcmanfm-qt].

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".

I've run strace -f on the above command, and none of the traced system
calls return ENOTSUP or EOPNOTSUPP

The same sftp:// URL works fine in filezilla, so I know the remote
server is OK.

The loan of a clue would be appreciated.

--
Grant

[gentoo-user] rsync local mirror question

[Walter Dnes]

  I followed https://wiki.gentoo.org/wiki/Local_Mirror instructions for
doing a local rsync mirror.  I ran commented the rsync mirrors line in
the client's make.conf and ran "emerge --sync".  The client still
synced from a server on the internet.  Do I need to manually force
rsync to go local, e.g...

[thimk][root][~] rsync 192.168.1.252::
gentoo-portage  Gentoo ebuild repository

-- 
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.