Re: Using etcupdate resolve, was Re: Surprise null root password

[bob prohaska]

I want to thank Patrick, Dmitry and Mark for providing
orientation sufficient to make some headway. The Handbook
simply says 

"If etcupdate(8) is not able to merge a file automatically, 
the merge conflicts can be resolved with manual interaction 
by issuing:

# etcupdate resolve

While not wrong, it's certainly less than the whole story 8-)

It's unfortunate that the example posted was a trivial case,
certainly I didn't tamper with BSD.tests.dist and tf was the
correct response. 

If I'm understanding correctly, the file presented by the
df and e options contains essentially all possible versions,
delimited by <, ||| and > 
characters. Once edited, that will become the new local
version of the file. If this is mistaken please say so.

bob prohaska

RE: Using etcupdate resolve, was Re: Surprise null root password

[Mark Millard]

[Note: In this 2nd try, I've indented everything by a tab
to help avoid reinterpretation/reformatting of some of the
text.]

I'm going to comment about the notations mean, not
about that the specific type of file is not one
you would be likely to have other than sn
official-content-only status for. My notes are yet
another alternative wording since you are
uncomfortable with things in this area, just in
case it helps.

bob prohaska  wrote on
Date: Thu, 15 Jun 2023 17:26:48 UTC :

>   Here's an example of the puzzles faced when using etcupdate
>   that have so far proved baffling:
> 
>   On running etcupdate resolve, the system reports
> 
>   Resolving conflict in '/etc/mtree/BSD.tests.dist':
>   Select: (p) postpone, (df) diff-full, (e) edit,
>   (h) help for more options: df
>   --- /etc/mtree/BSD.tests.dist   2023-05-29 08:29:48.174762000 -0700
>   +++ /var/db/etcupdate/conflicts/etc/mtree/BSD.tests.dist
> 2023-06-13 22:55:04.284491000 -0700
>   @@ -442,6 +442,16 @@
>..
>ifconfig
>..
>   +<<< yours
>   +||| original
>   +md5
>   +..
>   +===
>   +ipfw
>   +..
>   +md5
>   +..
>   +>>> new
>mdconfig
>..
>nvmecontrol
>   Select: (p) postpone, (df) diff-full, (e) edit,
>   (h) help for more options: e
> 
>   Selecting option e for edit brings up what appears to be a
>   vi window, using search I can find the line with mdconfig:
> 

For:

>   <<< yours
>   ||| original
>   md5
>   ..
>   ===
>   ipfw
>   ..
>   md5
>   ..
>   >>> new

The:

||| original
md5
..
===

indicates the prior official version's material
(the middle two lines of the 4 in this case).

The:

<<< yours
||| original

has an empty middle indicating what was found
in the file on your machine. The empty middle
indicates that the "md5" and ".." lines had
been deleted somehow, relative to want was
official.

The:

===
ipfw
..
md5
..
>>> new

indicates the new official version's content
for what originally had just the "md" and ".."
lines.

You might pick one of the 3 blocks to keep and delete
the rest of the lines (including ..., ...,
and ...) or you might replace everything
from ... to ... (inclusive) with the text that
you know you want in that area.

(In this case you likely want the new text that also
has "ipfw" material included.)

It is possible for a file to have multiple of these
kinds of "yours...original...new" blocks in the
file.

>   mdconfig
>   ..
>   nvmecontrol
>   ..
>   pfctl
>   files
>   ..
>   ..
>   ping
>   ..
> 
>   The puzzle at this point is what to do. It's looks like the
>   points of interest are the lines marked "yours" and "new",
>   but I'll admit to bafflement which to modify and whether
>   the modifications needed include the  and > characters.
> 
>   If there's a relevant man section please point it out.

"man git-merge" has the following text describing such notations:
(Again I'm not sure how nice the display will end up being.)

   An alternative style can be used by setting the 
"merge.conflictStyle"
   configuration variable to either "diff3" or "zdiff3". In "diff3" 
style,
   the above conflict may look like this:

   Here are lines that are either unchanged from the common
   ancestor, or cleanly resolved because only one side changed,
   <<< yours:sample.txt
   or cleanly resolved because both sides changed the same way.
   Conflict resolution is hard;
   let's go shopping.
   ||| base:sample.txt
   or cleanly resolved because both sides changed identically.
   Conflict resolution is hard.
   ===
   or cleanly resolved because both sides changed the same way.
   Git makes conflict resolution easy.
   >>> theirs:sample.txt
   And here is another line that is cleanly resolved or 
unmodified.


   while in "zdiff3" style, it may look like this:

   Here are 

Re: Using etcupdate resolve, was Re: Surprise null root password

[Dimitry Andric]

On 15 Jun 2023, at 19:26, bob prohaska  wrote:
> 
> Here's an example of the puzzles faced when using etcupdate
> that have so far proved baffling:
> 
> On running etcupdate resolve, the system reports
> 
> Resolving conflict in '/etc/mtree/BSD.tests.dist':
> Select: (p) postpone, (df) diff-full, (e) edit,
>(h) help for more options: df
> --- /etc/mtree/BSD.tests.dist 2023-05-29 08:29:48.174762000 -0700
> +++ /var/db/etcupdate/conflicts/etc/mtree/BSD.tests.dist 2023-06-13 
> 22:55:04.284491000 -0700
> @@ -442,6 +442,16 @@
> ..
> ifconfig
> ..
> +<<< yours
> +||| original
> +md5
> +..
> +===
> +ipfw
> +..
> +md5
> +..
> +>>> new
> mdconfig
> ..
> nvmecontrol
> Select: (p) postpone, (df) diff-full, (e) edit,
>(h) help for more options: e

Apparently etcupdate has concluded that you have modified BSD.tests.dist
from its original version. If you know for sure that you never modified
that file, it is easier to simply accept the "upstream" changes, by
typing "tf" (for "theirs-full") in the Select: prompt.

NOTE: NEVER do that for /etc/master.passwd and other important files in
/etc, at least not without backing them up!

In any case, like other three-way merging tools, it tries to piece together 
three parts:
1) the version of the file you actually have on disk
2) the old version from upstream
3) the new version from upstream

The 1) part is displayed from "<<<" onwards, the 2) part is
displayed from "|||" onwards, and the 3) part is displayed from
"===" until the final ">>>".

As long as 1) and 2) are exactly equal, etcupdate can simply apply the
diff between 2) and 3) without any problems, and you don't have to do
anything

However, once you start editing 1), it can not always automatically
apply the diff between 2) and 3), specifically when you have edited the
part(s) affected by that diff.

In that case, it shows the type of prompt you listed above. Typically, a
human has to look at the 'yours' (1), 'original' (2) and 'new' (3)
sections, and figure out what the result should be.

For example, in the above case, it seems that you deleted the "md5" and
".." lines from the BSD.tests.dist file, and since the update tries to
add new "ipfw" and ".." lines just above that, it does not know what to
do. If you intentionally got rid of the "md5' and ".." lines, you can
remove those from the 'new' section, and leave only the 'new' section.
Resulting in:

..
ifconfig
..
ipfw
..
mdconfig
..
nvmecontrol

And then this particular conflict has been resolved. If you use git a
lot, you get *very* familiar with this process. :-)

There are also lots of third-party tools to help you graphically resolve
these so-called three-way merges, see for example
.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Using etcupdate resolve, was Re: Surprise null root password

[Patrick M. Hausen]

Hi,

> Am 15.06.2023 um 19:26 schrieb bob prohaska :
> The puzzle at this point is what to do. It's looks like the
> points of interest are the lines marked "yours" and "new",
> but I'll admit to bafflement which to modify and whether
> the modifications needed include the  and > characters.

Everything between the line labelled "yours" and the line "==="
is your version. Everything between the line "===" and the line
labelled "new" is the new version.

You are supposed to bring the file to the desired final state
removing all three "marker" lines.

So in the two simple cases to keep your version delete the
line labelled "yours" and everything from "===" to
"new" including the markers.

To keep the new version delete everything from "yours"
to "===" including the markers and delete the marker "new".

Or any combination thereof. Produce a syntactically correct config
file with the desired content and remove all the markers.

I don't know if there is any documentation. When I first encountered
that during freebsd-update it looked obvious to me what to do.

HTH,
Patrick

Using etcupdate resolve, was Re: Surprise null root password

[bob prohaska]

Here's an example of the puzzles faced when using etcupdate
that have so far proved baffling:

On running etcupdate resolve, the system reports

Resolving conflict in '/etc/mtree/BSD.tests.dist':
Select: (p) postpone, (df) diff-full, (e) edit,
(h) help for more options: df
--- /etc/mtree/BSD.tests.dist   2023-05-29 08:29:48.174762000 -0700
+++ /var/db/etcupdate/conflicts/etc/mtree/BSD.tests.dist2023-06-13 
22:55:04.284491000 -0700
@@ -442,6 +442,16 @@
 ..
 ifconfig
 ..
+<<< yours
+||| original
+md5
+..
+===
+ipfw
+..
+md5
+..
+>>> new
 mdconfig
 ..
 nvmecontrol
Select: (p) postpone, (df) diff-full, (e) edit,
(h) help for more options: e

Selecting option e for edit brings up what appears to be a
vi window, using search I can find the line with mdconfig:

<<< yours
||| original
md5
..
===
ipfw
..
md5
..
>>> new
mdconfig
..
nvmecontrol
..
pfctl
files
..
..
ping
..

The puzzle at this point is what to do. It's looks like the
points of interest are the lines marked "yours" and "new",
but I'll admit to bafflement which to modify and whether
the modifications needed include the  and > characters.

If there's a relevant man section please point it out.  
 
Thanks for reading,

bob prohaska
 

Re: Surprise null root password

[David Chisnall]

On 30/05/2023 20:11, Dag-Erling Smørgrav wrote:

David Chisnall  writes:

There was a very nasty POLA violation a release or two ago.  OpenSSH
defaults to disallowing empty passwords and so having a null password
was a convenient way of allowing people to su or locally log into that
user but disallowing ssh.  This option does not work in recent
versions of FreeBSD.  Turning on the option to permit root login while
keeping the root password blank used to be (mostly) safe because it
permitted su to root from people in the wheel group, root login via
SSH key remotely (for ‘everything is broken I can’t log in as a user
whose home directory is not on the root filesystem’ recovery) and
local login as root from consoles marked as secure.  It now permits
root login from the network with a blank password.

That is incorrect.  PermitRootLogin defaults to “no” in FreeBSD and to
“prohibit-password” upstream (and presumably in the port), while
PermitEmptyPasswords defaults to “no” both in FreeBSD and upstream,
cf. crypto/openssh/servconf.c (search for “permit_root” and
“permit_empty”).


I didn't say it defaulted to anything else, but if you enable 
PermitRootLogin then you have a nasty surprise because 
PermitEmptyPasswords=no does not do anything and you can still log in 
via an empty password.


There is presumably something I can put in pam.d that will prevent 
password-based login (without fully disabling keyboard-interactive from 
sshd_config) but I have never successfully understood anything after 
reading the PAM documentation.


David

Re: Surprise null root password

[Alexander Leidinger]

Quoting bob prohaska  (from Tue, 30 May 2023  
08:36:21 -0700):



I suggest to review changes ("df" instead of "tf" in etcupdate) to at least
those files which you know you have modified, including the password/group
stuff. After that you can decide if the diff which is shown with "df" can be
applied ("tf"), or if you want to keep the old version ("mf"), or if you
want to modify the current file ("e", with both versions present in the file
so that you can copy/paste between the different versions and keep what you
need).



The key sequences required to copy and paste between files in the edit screen
were elusive. Probably it was thought self-evident, but not for me.  
I last tried
it long ago, via mergemaster. Is there is a guide to commands for  
merging files

using /etcupdate? Is it in the vi man page? I couldn't find it.


etcupdate respects the EDITOR env-variable. You can use any editor you  
like there.


Typically I use the mouse to copy myself and google every time I  
can't (https://linuxize.com/post/how-to-copy-cut-paste-in-vim/).


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgp4RaBvVQJjb.pgp
Description: Digitale PGP-Signatur

Re: Surprise null root password

[Mark Millard]

On May 30, 2023, at 18:39, bob prohaska  wrote:

> On Tue, May 30, 2023 at 11:02:13AM -0700, Mark Millard wrote:
>> bob prohaska  wrote on
>> Date: Tue, 30 May 2023 15:36:21 UTC :
>> 
>>> On Tue, May 30, 2023 at 08:41:33AM +0200, Alexander Leidinger wrote:
 
 Quoting bob prohaska  (from Fri, 26 May 2023 16:26:06
 -0700):
 
> On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote:
>> 
>> The question is how you update the configuration files,
>> mergemaster/etcupdate/something else?
>> 
> 
> Via etcupdate after installworld. In the event the system
> requests manual intervention I accept "theirs all". It seems
> odd if that can null a root password.
> 
> Still, it does seem an outside possibility. I could see it adding
> system users, but messing with root's existing password seems a
> bit unexpected.
 
 As you are posting to -current@, I expect you to report this issue about
 14-current systems. As such: there was a "recent" change (2021-10-20) to 
 the
 root entry to change the shell.
 https://cgit.freebsd.org/src/commit/etc/master.passwd?id=d410b585b6f00a26c2de7724d6576a3ea7d548b7
 
 By blindly accepting all changes, this has reset the PW to the default
 setting (empty).
>>> 
>>> So it's a line-by-line merge. That's the most sensible explanation 
>>> available.
>>> 
 
 I suggest to review changes ("df" instead of "tf" in etcupdate) to at least
 those files which you know you have modified, including the password/group
 stuff. After that you can decide if the diff which is shown with "df" can 
 be
 applied ("tf"), or if you want to keep the old version ("mf"), or if you
 want to modify the current file ("e", with both versions present in the 
 file
 so that you can copy/paste between the different versions and keep what you
 need).
 
>>> 
>>> The key sequences required to copy and paste between files in the edit 
>>> screen
>>> were elusive. Probably it was thought self-evident, but not for me. I last 
>>> tried 
>>> it long ago, via mergemaster. Is there is a guide to commands for merging 
>>> files 
>>> using /etcupdate? Is it in the vi man page? I couldn't find it.
>> 
>> # man etcpudate
>> . . .
>> CONFIG FILE
>> The etcupdate utility can also be configured by setting variables in an
>> optional configuration file named /etc/etcupdate.conf.  Note that command
>> line options override settings in the configuration file.  The
>> configuration file is executed by sh(1), so it uses that syntax to set
>> configuration variables.  The following variables can be set:
>> 
>> . . .
>> 
>> EDITOR  Specify a program to edit merge conflicts.
>> . . .
>> ENVIRONMENT
>> The etcupdate utility uses the program identified in the EDITOR
>> environment variable to edit merge conflicts.  If EDITOR is not set,
>> vi(1) is used as the default editor.
>> 
>> 
>> 
>> So, if you do not want to use vi, you can use either the EDITOR
>> environment variable or an EDITOR assignment in
>> /etc/etcupdate.conf to change what editor etcupdate uses for
>> you to edit merge conflicts with.
> 
> My difficulty is precisely a lack of skill with vi, which I've
> used and cursed since starting with 386BSD. Evidently I'm a slow
> learner I tried other editors, but vi is the only one always
> available.  

Well, there is ed ( and red ). But also built into FreeBSD is:
ee ( and ree ). Beyond that you might have to install something.

But if "always available" means across operating systems and
built-in, instead of needing to be installed, it may be the
most common for unixish contexts.  But, as I understand, some
Linux based OS's do not include (any variant of) vi, having
things like, say, nano instead. Some variant of vi would be
an install in such cases.

I went something like 25 years between usage of vi and could do
basic activity right off the bat. (Not that I was sure such would
be true when I first had to edit via whatever editor I could find
pre-installed at the time.) It is the only non-GUI editor for
which such a thing has been true. Why it stuck so well, I do not
know.

An odd thing about this is that before the 25 year interval, my
primary editor expertise was using TECO, including tailoring its
interactive use. At this point, I only remember the name.

> For the moment, etcupgrade isn't asking for manual intervention.
> When it next does I'll pay closer attention and ask better questions.
> 


===
Mark Millard
marklmi at yahoo.com

Re: Surprise null root password

[bob prohaska]

On Tue, May 30, 2023 at 11:02:13AM -0700, Mark Millard wrote:
> bob prohaska  wrote on
> Date: Tue, 30 May 2023 15:36:21 UTC :
> 
> > On Tue, May 30, 2023 at 08:41:33AM +0200, Alexander Leidinger wrote:
> > > 
> > > Quoting bob prohaska  (from Fri, 26 May 2023 16:26:06
> > > -0700):
> > > 
> > > > On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote:
> > > > > 
> > > > > The question is how you update the configuration files,
> > > > > mergemaster/etcupdate/something else?
> > > > > 
> > > > 
> > > > Via etcupdate after installworld. In the event the system
> > > > requests manual intervention I accept "theirs all". It seems
> > > > odd if that can null a root password.
> > > > 
> > > > Still, it does seem an outside possibility. I could see it adding
> > > > system users, but messing with root's existing password seems a
> > > > bit unexpected.
> > > 
> > > As you are posting to -current@, I expect you to report this issue about
> > > 14-current systems. As such: there was a "recent" change (2021-10-20) to 
> > > the
> > > root entry to change the shell.
> > > https://cgit.freebsd.org/src/commit/etc/master.passwd?id=d410b585b6f00a26c2de7724d6576a3ea7d548b7
> > > 
> > > By blindly accepting all changes, this has reset the PW to the default
> > > setting (empty).
> > 
> > So it's a line-by-line merge. That's the most sensible explanation 
> > available.
> > 
> > > 
> > > I suggest to review changes ("df" instead of "tf" in etcupdate) to at 
> > > least
> > > those files which you know you have modified, including the password/group
> > > stuff. After that you can decide if the diff which is shown with "df" can 
> > > be
> > > applied ("tf"), or if you want to keep the old version ("mf"), or if you
> > > want to modify the current file ("e", with both versions present in the 
> > > file
> > > so that you can copy/paste between the different versions and keep what 
> > > you
> > > need).
> > > 
> > 
> > The key sequences required to copy and paste between files in the edit 
> > screen
> > were elusive. Probably it was thought self-evident, but not for me. I last 
> > tried 
> > it long ago, via mergemaster. Is there is a guide to commands for merging 
> > files 
> > using /etcupdate? Is it in the vi man page? I couldn't find it.
> 
> # man etcpudate
> . . .
> CONFIG FILE
>  The etcupdate utility can also be configured by setting variables in an
>  optional configuration file named /etc/etcupdate.conf.  Note that command
>  line options override settings in the configuration file.  The
>  configuration file is executed by sh(1), so it uses that syntax to set
>  configuration variables.  The following variables can be set:
> 
>  . . .
> 
>  EDITOR  Specify a program to edit merge conflicts.
> . . .
> ENVIRONMENT
>  The etcupdate utility uses the program identified in the EDITOR
>  environment variable to edit merge conflicts.  If EDITOR is not set,
>  vi(1) is used as the default editor.
> 
> 
> 
> So, if you do not want to use vi, you can use either the EDITOR
> environment variable or an EDITOR assignment in
> /etc/etcupdate.conf to change what editor etcupdate uses for
> you to edit merge conflicts with.

My difficulty is precisely a lack of skill with vi, which I've
used and cursed since starting with 386BSD. Evidently I'm a slow
learner I tried other editors, but vi is the only one always
available.  

For the moment, etcupgrade isn't asking for manual intervention.
When it next does I'll pay closer attention and ask better questions.

Thanks to you in particular and everybody else who has helped!

bob prohaska

Re: Surprise null root password

[Marek Zarychta]

W dniu 26.05.2023 o 19:35, bob prohaska pisze:

While going through normal security email from a Pi2
running -current I was disturbed to find:

Checking for passwordless accounts:
root::0:0::0:0:Charlie &:/root:/bin/sh


This thread reminded me of another issue with passwords I encountered a 
few years ago.


Setting stronger passwords by users can be enforced by pam_passwdqc(8). 
But if the password expiration policy is enabled, it doesn't work since 
the password change for expired passwords is called by ssh or login PAM 
module, thus to enforce stronger passwords for users with passwords 
expired pam_passwdqc should be added also to both: 
/etc/pam.d/{login,sshd}, otherwise user with an expired password just 
presses return twice during the login prompt and has an empty password 
set. I even have risen D27656 some time ago, but it had gained not much 
interest except for some rephrasing/grammar advice.


So to use a password expiration policy and enforce high-quality 
passwords together, pam_passwdqc(8) has to activated in the three:  
/etc/pam.d/{login,passwd,sshd}.


Cheers

--
Marek Zarychta

Re: Surprise null root password

[Dag-Erling Smørgrav]

David Chisnall  writes:
> There was a very nasty POLA violation a release or two ago.  OpenSSH
> defaults to disallowing empty passwords and so having a null password
> was a convenient way of allowing people to su or locally log into that
> user but disallowing ssh.  This option does not work in recent
> versions of FreeBSD.  Turning on the option to permit root login while
> keeping the root password blank used to be (mostly) safe because it
> permitted su to root from people in the wheel group, root login via
> SSH key remotely (for ‘everything is broken I can’t log in as a user
> whose home directory is not on the root filesystem’ recovery) and
> local login as root from consoles marked as secure.  It now permits
> root login from the network with a blank password.

That is incorrect.  PermitRootLogin defaults to “no” in FreeBSD and to
“prohibit-password” upstream (and presumably in the port), while
PermitEmptyPasswords defaults to “no” both in FreeBSD and upstream,
cf. crypto/openssh/servconf.c (search for “permit_root” and
“permit_empty”).

DES
-- 
Dag-Erling Smørgrav - d...@freebsd.org

Re: Surprise null root password

[Mark Millard]

bob prohaska  wrote on
Date: Tue, 30 May 2023 15:36:21 UTC :

> On Tue, May 30, 2023 at 08:41:33AM +0200, Alexander Leidinger wrote:
> > 
> > Quoting bob prohaska  (from Fri, 26 May 2023 16:26:06
> > -0700):
> > 
> > > On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote:
> > > > 
> > > > The question is how you update the configuration files,
> > > > mergemaster/etcupdate/something else?
> > > > 
> > > 
> > > Via etcupdate after installworld. In the event the system
> > > requests manual intervention I accept "theirs all". It seems
> > > odd if that can null a root password.
> > > 
> > > Still, it does seem an outside possibility. I could see it adding
> > > system users, but messing with root's existing password seems a
> > > bit unexpected.
> > 
> > As you are posting to -current@, I expect you to report this issue about
> > 14-current systems. As such: there was a "recent" change (2021-10-20) to the
> > root entry to change the shell.
> > https://cgit.freebsd.org/src/commit/etc/master.passwd?id=d410b585b6f00a26c2de7724d6576a3ea7d548b7
> > 
> > By blindly accepting all changes, this has reset the PW to the default
> > setting (empty).
> 
> So it's a line-by-line merge. That's the most sensible explanation available.
> 
> > 
> > I suggest to review changes ("df" instead of "tf" in etcupdate) to at least
> > those files which you know you have modified, including the password/group
> > stuff. After that you can decide if the diff which is shown with "df" can be
> > applied ("tf"), or if you want to keep the old version ("mf"), or if you
> > want to modify the current file ("e", with both versions present in the file
> > so that you can copy/paste between the different versions and keep what you
> > need).
> > 
> 
> The key sequences required to copy and paste between files in the edit screen
> were elusive. Probably it was thought self-evident, but not for me. I last 
> tried 
> it long ago, via mergemaster. Is there is a guide to commands for merging 
> files 
> using /etcupdate? Is it in the vi man page? I couldn't find it.

# man etcpudate
. . .
CONFIG FILE
 The etcupdate utility can also be configured by setting variables in an
 optional configuration file named /etc/etcupdate.conf.  Note that command
 line options override settings in the configuration file.  The
 configuration file is executed by sh(1), so it uses that syntax to set
 configuration variables.  The following variables can be set:

 . . .

 EDITOR  Specify a program to edit merge conflicts.
. . .
ENVIRONMENT
 The etcupdate utility uses the program identified in the EDITOR
 environment variable to edit merge conflicts.  If EDITOR is not set,
 vi(1) is used as the default editor.



So, if you do not want to use vi, you can use either the EDITOR
environment variable or an EDITOR assignment in
/etc/etcupdate.conf to change what editor etcupdate uses for
you to edit merge conflicts with.


===
Mark Millard
marklmi at yahoo.com

Re: Surprise null root password

[Yetoo]

On Tue, May 30, 2023 at 8:36 AM bob prohaska  wrote:
>
> On Tue, May 30, 2023 at 08:41:33AM +0200, Alexander Leidinger wrote:
> >
> > Quoting bob prohaska  (from Fri, 26 May 2023 16:26:06
> > -0700):
> >
> > > On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote:
> > > >
> > > > The question is how you update the configuration files,
> > > > mergemaster/etcupdate/something else?
> > > >
> > >
> > > Via etcupdate after installworld. In the event the system
> > > requests manual intervention I accept "theirs all". It seems
> > > odd if that can null a root password.
> > >
> > > Still, it does seem an outside possibility. I could see it adding
> > > system users, but messing with root's existing password seems a
> > > bit unexpected.
> >
> > As you are posting to -current@, I expect you to report this issue about
> > 14-current systems. As such: there was a "recent" change (2021-10-20) to the
> > root entry to change the shell.
> > https://cgit.freebsd.org/src/commit/etc/master.passwd?id=d410b585b6f00a26c2de7724d6576a3ea7d548b7
> >
> > By blindly accepting all changes, this has reset the PW to the default
> > setting (empty).
>
> So it's a line-by-line merge. That's the most sensible explanation available.
>
> >
> > I suggest to review changes ("df" instead of "tf" in etcupdate) to at least
> > those files which you know you have modified, including the password/group
> > stuff. After that you can decide if the diff which is shown with "df" can be
> > applied ("tf"), or if you want to keep the old version ("mf"), or if you
> > want to modify the current file ("e", with both versions present in the file
> > so that you can copy/paste between the different versions and keep what you
> > need).
> >
>
> The key sequences required to copy and paste between files in the edit screen
> were elusive. Probably it was thought self-evident, but not for me. I last 
> tried
> it long ago, via mergemaster. Is there is a guide to commands for merging 
> files
> using /etcupdate? Is it in the vi man page? I couldn't find it.
>
> Thanks for writing!
>
> bob prohaska
>
>

It's been a while for me so I forget if etcupdate resolve is automatic
or there is a prompt or message about it, but the guide at
https://docs.freebsd.org/en/books/handbook/cutting-edge/#updating-src-completing-merge-etcupdate
says:
If etcupdate(8) is not able to merge a file automatically, the merge
conflicts can be resolved with manual interaction by issuing:
# etcupdate resolve

But this info is far below the steps at
https://docs.freebsd.org/en/books/handbook/cutting-edge/#updating-src-quick-start
with section 25.6.6.1 also not being mentioned in the steps.

Info on merge commands, regardless, is under the Resolve Mode
description in the etcupdate man page
https://man.freebsd.org/cgi/man.cgi?etcupdate.

Re: Surprise null root password

[bob prohaska]

On Tue, May 30, 2023 at 08:41:33AM +0200, Alexander Leidinger wrote:
> 
> Quoting bob prohaska  (from Fri, 26 May 2023 16:26:06
> -0700):
> 
> > On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote:
> > > 
> > > The question is how you update the configuration files,
> > > mergemaster/etcupdate/something else?
> > > 
> > 
> > Via etcupdate after installworld. In the event the system
> > requests manual intervention I accept "theirs all". It seems
> > odd if that can null a root password.
> > 
> > Still, it does seem an outside possibility. I could see it adding
> > system users, but messing with root's existing password seems a
> > bit unexpected.
> 
> As you are posting to -current@, I expect you to report this issue about
> 14-current systems. As such: there was a "recent" change (2021-10-20) to the
> root entry to change the shell.
> https://cgit.freebsd.org/src/commit/etc/master.passwd?id=d410b585b6f00a26c2de7724d6576a3ea7d548b7
> 
> By blindly accepting all changes, this has reset the PW to the default
> setting (empty).

So it's a line-by-line merge. That's the most sensible explanation available.

> 
> I suggest to review changes ("df" instead of "tf" in etcupdate) to at least
> those files which you know you have modified, including the password/group
> stuff. After that you can decide if the diff which is shown with "df" can be
> applied ("tf"), or if you want to keep the old version ("mf"), or if you
> want to modify the current file ("e", with both versions present in the file
> so that you can copy/paste between the different versions and keep what you
> need).
> 

The key sequences required to copy and paste between files in the edit screen
were elusive. Probably it was thought self-evident, but not for me. I last 
tried 
it long ago, via mergemaster. Is there is a guide to commands for merging files 
using /etcupdate? Is it in the vi man page? I couldn't find it.

Thanks for writing!

bob prohaska

Re: Surprise null root password

[Alexander Leidinger]

Quoting bob prohaska  (from Fri, 26 May 2023  
16:26:06 -0700):



On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote:


The question is how you update the configuration files,
mergemaster/etcupdate/something else?



Via etcupdate after installworld. In the event the system
requests manual intervention I accept "theirs all". It seems
odd if that can null a root password.

Still, it does seem an outside possibility. I could see it adding
system users, but messing with root's existing password seems a
bit unexpected.


As you are posting to -current@, I expect you to report this issue  
about 14-current systems. As such: there was a "recent" change  
(2021-10-20) to the root entry to change the shell.
 
https://cgit.freebsd.org/src/commit/etc/master.passwd?id=d410b585b6f00a26c2de7724d6576a3ea7d548b7


By blindly accepting all changes, this has reset the PW to the default  
setting (empty).


I suggest to review changes ("df" instead of "tf" in etcupdate) to at  
least those files which you know you have modified, including the  
password/group stuff. After that you can decide if the diff which is  
shown with "df" can be applied ("tf"), or if you want to keep the old  
version ("mf"), or if you want to modify the current file ("e", with  
both versions present in the file so that you can copy/paste between  
the different versions and keep what you need).


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF


pgpGEjDP92h3s.pgp
Description: Digitale PGP-Signatur

Re: Surprise null root password

[Rodney W. Grimes]

> It turns out all seven hosts in my cluster report
> a null password for root in /usr/src/etc/master.passwd:
> root::0:0::0:0:Charlie &:/root:/bin/sh
> 
> Is that intentional?

No, but I suspect your build/update procedures are infact telling
the system to do this.  Someone else pointed out etcupdate, which
iirc you are using, with the update of "thiers all" infact would
overwrite /etc/master.passwd.  I do not know that etcupdate has
the smarts to know that if it overwrites /etc/master.passwd it
needs to run a pwd_mkdb -p /etc/master.passwd.  etcupdate infact
does have the smarts to run a pwd_mkdb.

Hum, it also has some special casing of PREWORLD_FILES, which 
is /etc/master.passwd and etc/group.  Perhaps something in that
process went wrong.

-- 
Rod Grimes rgri...@freebsd.org

Re: Surprise null root password

[Rodney W. Grimes]

> On 26 May 2023, at 12:35, bob prohaska wrote:
> 
> > While going through normal security email from a Pi2
> > running -current I was disturbed to find:
> >
> > Checking for passwordless accounts:
> > root::0:0::0:0:Charlie &:/root:/bin/sh
> >
> > The machine had locked up on a -j4 buildworld since
> > sending the mail, so it was taken off the net, power
> > cycled and started single-user.
> >
> > Sure enough, /etc/master.passwd contained a
> > null password for root, but the last modification
> > to the file was two weeks ago according to ls -l.
> >
> > Stranger still, when fsck'd and brought up multi-user,
> > the normal password was still honored and a null
> > password rejected for both regular and root account.
> >
> > AFAIK, /etc/master.passwd is _the_ password repository,
> > but clearly I'm wrong.
> 
> /etc/master.passwd is the source, but the operational database
> is /etc/spwd.db.  You should check the date on it as well.
> You can rebuild it with ?pwd_mkdb -p /etc/master.passwd?.

BUT if infact /etc/master.passwd has been clobbered, BUT
/etc/spwd.db still contains the correct data you would not
want to do the above, as that would put the null passwd
for root into /etc/*pwd.db, and/or possible other accounts.

I do not know of a utility that can dump /etc/*pwd.db and
recreate a master.passwd file, anyone?

>   Mike
> 
> > If somebody can tell me what's going on and what to
> > check for before placing the machine back on line
> > it would be much appreciated.
> >
> > Thanks for reading,
> >
> > bob prohaska
> 
> 

-- 
Rod Grimes rgri...@freebsd.org

Re: Surprise null root password

[David Chisnall]

On 27 May 2023, at 03:52, Mike Karels  wrote:
> 
> On 26 May 2023, at 21:28, bob prohaska wrote:
> 
>> It turns out all seven hosts in my cluster report
>> a null password for root in /usr/src/etc/master.passwd:
>> root::0:0::0:0:Charlie &:/root:/bin/sh
>> 
>> Is that intentional?
> 
> Well, it has been that way in FreeBSD since 1993, and in BSD since
> 1980 (4.0BSD).  I guess you would say that it is intentional.  The
> alternative would be to have a well-known password like root, but
> then it wouldn’t be as obvious that a local password had not been
> set.

There was a very nasty POLA violation a release or two ago.  OpenSSH defaults 
to disallowing empty passwords and so having a null password was a convenient 
way of allowing people to su or locally log into that user but disallowing ssh. 
 This option does not work in recent versions of FreeBSD.  Turning on the 
option to permit root login while keeping the root password blank used to be 
(mostly) safe because it permitted su to root from people in the wheel group, 
root login via SSH key remotely (for ‘everything is broken I can’t log in as a 
user whose home directory is not on the root filesystem’ recovery) and local 
login as root from consoles marked as secure.  It now permits root login from 
the network with a blank password.

David

Re: Surprise null root password

[Mike Karels]

On 26 May 2023, at 21:28, bob prohaska wrote:

> It turns out all seven hosts in my cluster report
> a null password for root in /usr/src/etc/master.passwd:
> root::0:0::0:0:Charlie &:/root:/bin/sh
>
> Is that intentional?

Well, it has been that way in FreeBSD since 1993, and in BSD since
1980 (4.0BSD).  I guess you would say that it is intentional.  The
alternative would be to have a well-known password like root, but
then it wouldn’t be as obvious that a local password had not been
set.

Mike

> Thanks for reading,
>
> bob prohaska

Re: Surprise null root password

[bob prohaska]

It turns out all seven hosts in my cluster report
a null password for root in /usr/src/etc/master.passwd:
root::0:0::0:0:Charlie &:/root:/bin/sh

Is that intentional?

Thanks for reading,

bob prohaska

Re: Surprise null root password

[Tomoaki AOKI]

On Fri, 26 May 2023 16:26:06 -0700
bob prohaska  wrote:

> On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote:
> > 
> > The question is how you update the configuration files,
> > mergemaster/etcupdate/something else?
> > 
> 
> Via etcupdate after installworld. In the event the system
> requests manual intervention I accept "theirs all". It seems
> odd if that can null a root password.
> 
> Still, it does seem an outside possibility. I could see it adding
> system users, but messing with root's existing password seems a
> bit unexpected.  
> 
> Thanks very much for raising the point!
> 
> bob prohaska

Maybe that's it.

As you chose "theirs all" (maybe theirs-full?), conflicted files
(include /etc/master.passwd) are overwritten by brand-new default ones.

You should choose "(e) edit" and manually merge them correctly.

-- 
Tomoaki AOKI

Re: Surprise null root password

[bob prohaska]

On Fri, May 26, 2023 at 10:55:49PM +0200, Yuri wrote:
> 
> The question is how you update the configuration files,
> mergemaster/etcupdate/something else?
> 

Via etcupdate after installworld. In the event the system
requests manual intervention I accept "theirs all". It seems
odd if that can null a root password.

Still, it does seem an outside possibility. I could see it adding
system users, but messing with root's existing password seems a
bit unexpected.  

Thanks very much for raising the point!

bob prohaska

Re: Surprise null root password

[Yuri]

bob prohaska wrote:
> On Fri, May 26, 2023 at 07:48:04PM +0100, Ben Laurie wrote:
>> -T on ls will give you full time resolution...
>>
> More's the wonder:
> root@www:/usr/src # ls -lT /etc/*p*wd*
> -rw---  1 root  wheel   2099 May 10 17:20:33 2023 /etc/master.passwd
> -rw-r--r--  1 root  wheel   1831 May 10 17:20:33 2023 /etc/passwd
> -rw-r--r--  1 root  wheel  40960 May 10 17:20:33 2023 /etc/pwd.db
> -rw---  1 root  wheel  40960 May 10 17:20:33 2023 /etc/spwd.db
> 
> For sake of clarity, /etc/master.passwd's root line is
> root::0:0::0:0:Charlie &:/root:/bin/sh
> while /etc/passwd's root line is
> root:*:0:0:Charlie &:/root:/bin/sh
> 
> I just noticed a second host (Pi3) which is similarly affected.
> It completed a build/install cycle on May 25, uname -a yields
> FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #46 
> main-n263122-57a3a161a92f: Thu May 25 21:25:57 PDT 2023 
> b...@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64
> 
> On this host I get
> root@www:/usr/src # ls -lT /etc/*p*wd*
> -rw---  1 root  wheel   1796 Nov 12 16:00:03 2022 /etc/master.passwd
> -rw-r--r--  1 root  wheel   2430 Oct  1 19:40:22 2020 /etc/passwd
> -rw-r--r--  1 root  wheel  40960 Oct  1 19:40:22 2020 /etc/pwd.db
> -rw---  1 root  wheel  40960 Oct  1 19:40:22 2020 /etc/spwd.db
> (at least the dates make more sense)
> 
> The root line in /etc/master.passwd is
> root::0:0::0:0:Charlie &:/root:/bin/sh
> 
> I didn't catch any null password reports in the security emails,
> most likely through lack of attention. As with the first case,
> passwords seem to work normally (null rejected, normal accepted).

The question is how you update the configuration files,
mergemaster/etcupdate/something else?

Re: Surprise null root password

[bob prohaska]

On Fri, May 26, 2023 at 07:48:04PM +0100, Ben Laurie wrote:
> -T on ls will give you full time resolution...
> 
More's the wonder:
root@www:/usr/src # ls -lT /etc/*p*wd*
-rw---  1 root  wheel   2099 May 10 17:20:33 2023 /etc/master.passwd
-rw-r--r--  1 root  wheel   1831 May 10 17:20:33 2023 /etc/passwd
-rw-r--r--  1 root  wheel  40960 May 10 17:20:33 2023 /etc/pwd.db
-rw---  1 root  wheel  40960 May 10 17:20:33 2023 /etc/spwd.db

For sake of clarity, /etc/master.passwd's root line is
root::0:0::0:0:Charlie &:/root:/bin/sh
while /etc/passwd's root line is
root:*:0:0:Charlie &:/root:/bin/sh

I just noticed a second host (Pi3) which is similarly affected.
It completed a build/install cycle on May 25, uname -a yields
FreeBSD www.zefox.org 14.0-CURRENT FreeBSD 14.0-CURRENT #46 
main-n263122-57a3a161a92f: Thu May 25 21:25:57 PDT 2023 
b...@www.zefox.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64

On this host I get
root@www:/usr/src # ls -lT /etc/*p*wd*
-rw---  1 root  wheel   1796 Nov 12 16:00:03 2022 /etc/master.passwd
-rw-r--r--  1 root  wheel   2430 Oct  1 19:40:22 2020 /etc/passwd
-rw-r--r--  1 root  wheel  40960 Oct  1 19:40:22 2020 /etc/pwd.db
-rw---  1 root  wheel  40960 Oct  1 19:40:22 2020 /etc/spwd.db
(at least the dates make more sense)

The root line in /etc/master.passwd is
root::0:0::0:0:Charlie &:/root:/bin/sh

I didn't catch any null password reports in the security emails,
most likely through lack of attention. As with the first case,
passwords seem to work normally (null rejected, normal accepted).

Any advice appreciated!

bob prohaska




> On Fri, 26 May 2023 at 19:45, bob prohaska  wrote:
> 
> > On Fri, May 26, 2023 at 01:03:19PM -0500, Mike Karels wrote:
> > > On 26 May 2023, at 12:35, bob prohaska wrote:
> > >
> > > > While going through normal security email from a Pi2
> > > > running -current I was disturbed to find:
> > > >
> > > > Checking for passwordless accounts:
> > > > root::0:0::0:0:Charlie &:/root:/bin/sh
> > > >
> > [details snipped]
> > > /etc/master.passwd is the source, but the operational database
> > > is /etc/spwd.db.  You should check the date on it as well.
> > > You can rebuild it with ???pwd_mkdb -p /etc/master.passwd???.
> >
> > At present the host reports:
> > root@www:/usr/src # ls -l /etc/*p*wd*
> > -rw---  1 root  wheel   2099 May 10 17:20 /etc/master.passwd
> > -rw-r--r--  1 root  wheel   1831 May 10 17:20 /etc/passwd
> > -rw-r--r--  1 root  wheel  40960 May 10 17:20 /etc/pwd.db
> > -rw---  1 root  wheel  40960 May 10 17:20 /etc/spwd.db
> >
> > /etc/master.passwd reports a null password for root, /etc/passwd
> > has the usual asterisk. The running system reports
> > root@www:/usr/src # uname -a
> > FreeBSD www.zefox.com 14.0-CURRENT FreeBSD 14.0-CURRENT #25
> > main-743516d51f: Thu May 18 00:08:40 PDT 2023 
> > b...@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC
> > arm
> > root@www:/usr/src # uname -KU
> > 1400088 1400088
> >
> > I've never manually run pwd_mkdb and most certainly
> > never set a null password for root. It looks rather
> > as if a null password was set for root within one
> > minute after running pwd_mkdb.
> >
> > At this point I'm unsure how to sort out what happened.
> > The obvious next step is to re-establish a non-null
> > root password and rebuild both databases.
> >
> > Is it worthwhile to check for backdoors? There's no
> > evidence to suggest any malicious action (and plenty
> > of stupidity on my end) but the tale is getting
> > curiouser and curiouser.
> >
> > Many thanks for the quick reply!
> >
> > bob prohaska
> >
> >
> >
> >
> >

Re: Surprise null root password

[Ben Laurie]

-T on ls will give you full time resolution...

On Fri, 26 May 2023 at 19:45, bob prohaska  wrote:

> On Fri, May 26, 2023 at 01:03:19PM -0500, Mike Karels wrote:
> > On 26 May 2023, at 12:35, bob prohaska wrote:
> >
> > > While going through normal security email from a Pi2
> > > running -current I was disturbed to find:
> > >
> > > Checking for passwordless accounts:
> > > root::0:0::0:0:Charlie &:/root:/bin/sh
> > >
> [details snipped]
> > /etc/master.passwd is the source, but the operational database
> > is /etc/spwd.db.  You should check the date on it as well.
> > You can rebuild it with ???pwd_mkdb -p /etc/master.passwd???.
>
> At present the host reports:
> root@www:/usr/src # ls -l /etc/*p*wd*
> -rw---  1 root  wheel   2099 May 10 17:20 /etc/master.passwd
> -rw-r--r--  1 root  wheel   1831 May 10 17:20 /etc/passwd
> -rw-r--r--  1 root  wheel  40960 May 10 17:20 /etc/pwd.db
> -rw---  1 root  wheel  40960 May 10 17:20 /etc/spwd.db
>
> /etc/master.passwd reports a null password for root, /etc/passwd
> has the usual asterisk. The running system reports
> root@www:/usr/src # uname -a
> FreeBSD www.zefox.com 14.0-CURRENT FreeBSD 14.0-CURRENT #25
> main-743516d51f: Thu May 18 00:08:40 PDT 2023 
> b...@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC
> arm
> root@www:/usr/src # uname -KU
> 1400088 1400088
>
> I've never manually run pwd_mkdb and most certainly
> never set a null password for root. It looks rather
> as if a null password was set for root within one
> minute after running pwd_mkdb.
>
> At this point I'm unsure how to sort out what happened.
> The obvious next step is to re-establish a non-null
> root password and rebuild both databases.
>
> Is it worthwhile to check for backdoors? There's no
> evidence to suggest any malicious action (and plenty
> of stupidity on my end) but the tale is getting
> curiouser and curiouser.
>
> Many thanks for the quick reply!
>
> bob prohaska
>
>
>
>
>

Re: Surprise null root password

[bob prohaska]

On Fri, May 26, 2023 at 01:03:19PM -0500, Mike Karels wrote:
> On 26 May 2023, at 12:35, bob prohaska wrote:
> 
> > While going through normal security email from a Pi2
> > running -current I was disturbed to find:
> >
> > Checking for passwordless accounts:
> > root::0:0::0:0:Charlie &:/root:/bin/sh
> >
[details snipped] 
> /etc/master.passwd is the source, but the operational database
> is /etc/spwd.db.  You should check the date on it as well.
> You can rebuild it with ???pwd_mkdb -p /etc/master.passwd???.

At present the host reports:
root@www:/usr/src # ls -l /etc/*p*wd*
-rw---  1 root  wheel   2099 May 10 17:20 /etc/master.passwd
-rw-r--r--  1 root  wheel   1831 May 10 17:20 /etc/passwd
-rw-r--r--  1 root  wheel  40960 May 10 17:20 /etc/pwd.db
-rw---  1 root  wheel  40960 May 10 17:20 /etc/spwd.db

/etc/master.passwd reports a null password for root, /etc/passwd
has the usual asterisk. The running system reports
root@www:/usr/src # uname -a
FreeBSD www.zefox.com 14.0-CURRENT FreeBSD 14.0-CURRENT #25 main-743516d51f: 
Thu May 18 00:08:40 PDT 2023 
b...@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm
root@www:/usr/src # uname -KU
1400088 1400088

I've never manually run pwd_mkdb and most certainly
never set a null password for root. It looks rather
as if a null password was set for root within one
minute after running pwd_mkdb.

At this point I'm unsure how to sort out what happened.
The obvious next step is to re-establish a non-null
root password and rebuild both databases. 

Is it worthwhile to check for backdoors? There's no
evidence to suggest any malicious action (and plenty
of stupidity on my end) but the tale is getting
curiouser and curiouser.

Many thanks for the quick reply!

bob prohaska
 

Re: Surprise null root password

[Mike Karels]

On 26 May 2023, at 12:35, bob prohaska wrote:

> While going through normal security email from a Pi2
> running -current I was disturbed to find:
>
> Checking for passwordless accounts:
> root::0:0::0:0:Charlie &:/root:/bin/sh
>
> The machine had locked up on a -j4 buildworld since
> sending the mail, so it was taken off the net, power
> cycled and started single-user.
>
> Sure enough, /etc/master.passwd contained a
> null password for root, but the last modification
> to the file was two weeks ago according to ls -l.
>
> Stranger still, when fsck'd and brought up multi-user,
> the normal password was still honored and a null
> password rejected for both regular and root account.
>
> AFAIK, /etc/master.passwd is _the_ password repository,
> but clearly I'm wrong.

/etc/master.passwd is the source, but the operational database
is /etc/spwd.db.  You should check the date on it as well.
You can rebuild it with “pwd_mkdb -p /etc/master.passwd”.

Mike

> If somebody can tell me what's going on and what to
> check for before placing the machine back on line
> it would be much appreciated.
>
> Thanks for reading,
>
> bob prohaska

Surprise null root password

[bob prohaska]

While going through normal security email from a Pi2
running -current I was disturbed to find:

Checking for passwordless accounts:
root::0:0::0:0:Charlie &:/root:/bin/sh

The machine had locked up on a -j4 buildworld since
sending the mail, so it was taken off the net, power
cycled and started single-user.

Sure enough, /etc/master.passwd contained a
null password for root, but the last modification
to the file was two weeks ago according to ls -l.

Stranger still, when fsck'd and brought up multi-user,
the normal password was still honored and a null
password rejected for both regular and root account.

AFAIK, /etc/master.passwd is _the_ password repository,
but clearly I'm wrong.

If somebody can tell me what's going on and what to
check for before placing the machine back on line
it would be much appreciated.

Thanks for reading,

bob prohaska