Hello:

Yes, it is.

But it is a local privilege escalation and (for now) it only affects sudo 1.9.14 to 1.9.17.

See here: https://gbhackers.com/poc-published-for … e-to-root/

I wonder what happened to do one thing and do it well?

That said, my up-to-date Devuan Daedalus (and yours) runs 1.9.13p3:

$ apt list | grep installed | grep sudo
--- snip ---
sudo/stable,stable-security,now 1.9.13p3-1+deb12u2 amd64 [installed]
$ 

So ...
Stay the course, everything wil be back to normal soon.

Best,

A.

Hello:

And now ... 
A side-note to a side-note.  ; ^ )

I have a Devuan Daedalus VM I can run (for experimental / testing purposes) on my Devuan Daedalus box.
It is the bog-standard image from the download repository and I can log in (via SLiM) as root:

# whoami
root
# 
# uname -a
Linux daedalus 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64 GNU/Linux
# 

My box works the same way.
I have no issue with that, just have to take the necessary precautions.

That said, I have never (ever) needed to do it.
I have specific sudoers entries for all-things I allow as sudo.

Best,

A.

Hello:

They may have moved somewhere less conspicuous.
ie: hidden it

Or maybe it has become a part of the systemd OS.

I don't have one in my Daedalus system: I deleted it.
No issues.

That one you can delete.
If what we have seen up to now holds, the system behaviour should be that the -0 file gets overwitten at boot.

Best,

A.

Hello:

Without knowing anything much about how/why this happens, what I have observed is that, wherever it is that a */.dbus/session-bus/ directory is located*, stale files remained.
ie: stale in the sense that they are session-id files belonging to previous sessions.
* /root, /home/user, /var/lib/lightdm or anywhere but /tmp

This is something that has (evidently) been happening for the longest while and gone unnoticed, never before reported as an anomaly.
A bug? Most probably.
A feature to track previous dbus sessions?
If so, to what practical end?

It is definitely related to installations with some sort of desktop or WM.
eg: my 1000HE runs a dated Devuan (5.10 kernel and Openbox) and when I went to look I found a staggering amount of stale files going back to 2017, which I promptly nuked.
Now, with @greenjean's script, that does not happen any more.
My headless Chimaera VM does not have a */.dbus/session-bus/ directory.

All this to say that this looks like a dbus problem albeit (most probably) related to systemd.

Just a guess, a possibly educated one.

Best,

A.

Hello:

Done.
From what I can see, works as advertised.  8^)
Logs to /var/log/user.log.

--- snip ---
Sep 19 18:28:03 devuan shutdown[11658]: shutting down for system halt
Sep 19 18:28:03 devuan rm-machineid: dbus session-bus cleanup: removing session-bus files
Sep 19 18:28:03 devuan rm-machineid: Cleaned /root/.dbus/session-bus
Sep 19 18:28:03 devuan rm-machineid: Cleaned /home/groucho/.dbus/session-bus
--- snip ---

Good job.

Best,

A.

Hello:

That certainly would not be me, so I cannot comment on it save to say that logging is a great idea.

What I can comment on, without any reservation, is your commitment to getting the problem solved.
And extend a heartfelt thank you for all the work you have put into doing so.

Kudos to you.

Best,

A.

Hello:

No, I get it.
The machine-id is used by .dbus.
The problem was having a fixed one, so I nuked /etc/machine-id.
Now I get a different one after every boot.
Which is what the patch mentioned in the ASCII release notes was for.

root@localhost:~# cat ~/.bash_logout
rm -f ~/.dbus/session-bus/*

Right.
That would (?) purge the random generated machine-id at every shutdown, solving the problem of the accumulation of files in ~/.dbus/session-bus.

But ...
That it is not what I see in my Daedalus installation:

$ cat ~/.bash_logout
# ~/.bash_logout: executed by bash(1) when login shell exits.
# when leaving the console clear the screen to increase privacy

if [ "$SHLVL" = 1 ]; then
    [ -x /usr/bin/clear_console ] && /usr/bin/clear_console -q
fi
$

[root@devuan ~]# cat ~/.bash_logout
cat: /root/.bash_logout: No such file or directory
[root@devuan ~]# 

^^^^ same as /etc/skel/.bash_logout

Maybe manually adding the script would do it?

There is a thread here at Dev1 related to ~/.bash_logout:
https://dev1galaxy.org/viewtopic.php?id=5559

Now, if this is right and agetty clears the screen by default, ~/.bash_logout would not be needed?

Thanks for your input.

Best,

A.

Hello:

@Rolfie

But it does ...

$ ls -l /etc/machine-id
-r--r--r-- 1 root root 33 Dec 13  2017 /etc/machine-id
$ 

And then the patch does not work.

@greenjeans

Right ...

I knew which one you were referring to because I had both seen it and remembered that I had seen it.
But, as you can gather *...

See the date and the attributes?
It has probably been there since my first Devuan Linux installation, Jesse.
The patch evidently did not act on an existing machine-id and so it remained static.

I'll nuke it, see what happens after a few reboots and report back, later or early tomorrow.

Sorry about the distraction. 8^/

Best,

A.

Hello:

Just checked my 1000HE netbook running Beowulf with a backported kernel.
Was never upgraded because I fear for my coffee roasting software.

Did not bother to count how many after I saw that the third MC screen passed by.
Must have been 600+ files which I promptly nuked, but it is just a guess.

Curiously enough, I never came across any line in dmesg (or other logs I look at) saying something about this in any one of my boxes, ever.
eg:

[000.0000] generating random machine-id

or

[000.0000] generating random machine-id failed - old machine-id used

Methinks that the patch applied to ASCII never really worked and if it did, it did so for just a short while or only in ASCII.
Not being something that would make a light blink (so to speak) it just laid there, dormant.
And nobody ever checked.

Till @greenjeans.  8^)

Best,

A.

Hello:

I thought as much, asked to verify.

Yes?
I don't see that happening.
ie: /etc/default/dbus is set to IDTYPE="RANDOM"  (see my previous post)
And it seems that I am not the only one.

Any idea why?
Is there a bug/problem to be addressed somewhere in my  system Devuan?
If so, it has been there since (at least) Jesse ASCII*.

*The dbus patch to generate new dbus machine-id on boot was added in ASCII.

Best,

A.

Hello:

Maybe, not necessarily.
At least not yet. 8^°

Which begs the following question:
In whose interests or (better yet, to what end) does my box/system need to have a unique machine-id.
ie: my machine-id seems to have been set long ago and it has not changed (much like your own situation) since 17/10/2018.

Best,

A.

Hello:

Why?

Not if it is (as you have mentioned) working properly.
ie: renewing the files on every boot.

Still, I did have those two very old files.

I rebooted after nuking the vintage files and the system replaced the previous valid one with a new one.
ie: just one file with the proper boot time/date present.

Lately I have mentioned that my present system ie: Daedalus started off as Jesse and from the date of the oldest file I found in the root didrectory, that would have been back in 2017.

Makes sense, my first post here is from that year.

The fact that this box has seen a succession of dist-upgrades, with all but one (a Beowulf to Chimaera nightmare) being reasonably smooth may have to be taken into account to evaluate this find.

Could it be that there was a change (or introduced bug) in how dbus managed those files and my system (at some point) retained a previous configuration? No idea, just a guess.

Let me know if you need more data.

Best,

A.