You are not logged in.
- Topics: Active | Unanswered
#726 Re: Other Issues » Ustable and Testing Systemd. » 2023-10-19 21:56:36
Hello:
Thanks ...
You're welcome.
... disappointing attitude ...
To say the least.
I don't, because it isn't ...
I meant solved for the OP who (because of Distrowatch) thought Unstable and Testing used systemd.
That was cleared up and ceased to be an issue for him.
On the other hand, what was not cleared up and you seem to have cracked, is the why Distrowatch has the wrong data or at the very least, misinterprets the available data, something which was beyond my intent.
And therein lies the lack of basic common sense / bad attitude from the chap at Distrowatch.
Devuan (let's accept that it was Devuan, just for argument's sake) is explaining that Unstable and Testing do not have/use systemd, that all those files are shims to be able to use some packages from the Debian repositories.
But no, they dig in deeper, wriggling their way out the argument and insisting.
Wouldn't it have been much more reasonable for them to have sent an email to the address I provided and simply ask?
Our dedicated Devuan devs would have asked about the source of their data and promptly cleared up the problem for them.
But no, no - can - do - that.
Not a problem, to me Distrowatch was never a place to go for distribution information.
It is just a long list of names.
Thank you for your input.
Best,
A.
#727 Re: Other Issues » OpenRC init script works fine on Gentoo and Artix – but not on Devuan » 2023-10-19 20:41:47
Hello:
... situation in that example is not the same as the situation here.
Indeed ...
It did not cross my mind.
I'm sorry if I explained myself incorrectly.
My comment was related exclusively to your asserting that Debian supports all packages in its repositories, installed by default or not.
My view of what transpired in the case I referenced is what I can understand from the maintainer's text within the context of the problem exposed.
ie:
Worked as expected with systemd but did not work with sysvinit.
The main difference, exhaustively documented, being the init software used.
Was there another gremlin at work there?
We don't/won't know.
The maintainer refused to have a look on the grounds of Debian+sysvinit not being a default configuration, his calification of the bug is of no import.
... sysvinit is not enabled by default in Debian ...
... do not consider this bug as release-critical.
Given what the Debian devs/maintainers are doing with the init scripts lately ...
Can anyone be at all surprised?
Thanks for your input.
Best,
A.
#728 Re: Other Issues » OpenRC init script works fine on Gentoo and Artix – but not on Devuan » 2023-10-19 15:39:26
Hello:
Any package you find in the Debian Stable repositories is supported by Debian - it doesn't matter if it is installed by default.
I would not be too sure about that.
ie: the "supported" and "it doesn't matter if it is installed by default" parts.
Some time ago there was a thread related to timeshift with a LUKS / btrfs combination and how it worked properly in Debian and not in Devuan.
After a long exchange of ideas here at Dev1, a bug was reported to Debian by the OP.
Quite obviously, Devuan was not mentioned.
The bug was reported to because timeshift (with the LUKS / btrfs combination) worked perfectly well with Debian+systemd but not with Debian+sysvinit.
If interested, see bug #1034328
The answer from Debian?
Since sysvinit is not enabled by default in Debian, I do not consider this
bug as release-critical. Downgrading the bug severity to "normal".
Best,
A.
#729 Re: Other Issues » Ustable and Testing Systemd. » 2023-10-17 22:30:37
Hello:
... kidding obviously.
Of course. 8^D
A.
#730 Re: Other Issues » Ustable and Testing Systemd. » 2023-10-16 17:14:52
Hello:
... it is needed for some systemd-less reason (elogind?) ...
Yes, not exactly but closely related to systemd.
Elogind is the systemd project's "logind", extracted out to be a standalone daemon. It integrates with PAM to know the set of users that are logged in to a system and whether they are logged in graphically, on the console, or remotely.
Xorg uses elogind to keep it from running as root.
Something which has always (rightly so) been a source of stern criticism.
See this post at the Artix forum for a quick explanation.
... elogind literally just sleeps 99% of the time.
It's a daemon.
Nothing harmful.
I think this thread can be marked as solved.
Best,
A.
#731 Re: Devuan » You are being hacked » 2023-10-16 15:52:27
Hello:
... appears to be something to do with seatd and or wayland.
I would not be surprised if it was related to wayland.
Why does mouse driven logout take forever.
Why does ctrl_alt_bksp not action immediately.
I don't use (or want/need to use) wayland, my box runs on X.
logout and/or ctrl_alt_bksp are practically instantaneous.
No delays at all.
The only thing that will cause a delay (quite obviously) in my box is a backintime process running.
I'd purge wayland and see what happens.
Best,
A.
#732 Re: Other Issues » Ustable and Testing Systemd. » 2023-10-16 10:53:42
Hello:
For example ...
The only reference to cgroups I have in /run/systemd is cgroups-agent, a Unix socket.
Location: /run/systemd
File type: socket
Total size of files: 0 bytes
Size on disk: 0 bytes
And then there's /lib/elogind/elogind-cgroups-agent which is a shared library.
I don't use Network Manager, my system uses Wicd.
From what I understand from the netstat-an printout, cgroups-agent is an active UNIX domain type socket with two attached processes, no 'Flags' data, used in DGRAM (connectionless) state.
ie: not waiting for a connect request, connected or listening
Proto unix
RefCnt 2 <-- attached processes
Flags [ ] <-- no flags - not waiting for a connect request
Type DGRAM <-- connectionless
State <-- empty - not connected to another socket
I-Node 15845
Path /run/systemd/cgroups-agentMy guess is that it is needed for some systemd-less reason (elogind?), otherwise it would not be there, but that's all I can say.
It is all rather over my head.
That said,a couple of questions pop-up:
- what does/would it take for the cgroups-agent socket lose its connectionless mode/state?
- what can be done to avoid that from ever happening? ie: some way to block/blacklist it
Thanks in advance.
Best,
A.
#733 Re: Other Issues » Ustable and Testing Systemd. » 2023-10-16 02:16:05
Hello:
Depending what iso you start from ...
I run Devuan Beowulf on a backported kernel ...
~$ uname -a
Linux devuan 5.10.0-0.deb10.16-amd64 #1 SMP Debian 5.10.127-2~bpo10+1 (2022-07-28) x86_64 GNU/Linux
~$ ... and I get this:
~$ netstat -an | grep systemd
unix 2 [ ] DGRAM 15854 /run/systemd/cgroups-agent
~$ I recall having seen it once or twice before but did not pay attention to it.
you can set a kernel variable to ignore / orphaned process.
Q1: why do I have this? What starts it?
Q2: is it doing anyhting? It does not seem to be listening or connected
Q3: how do I get rid of it? (kernel variable?)
Thanks in advance.
Best.
A.
#734 Re: Other Issues » Ustable and Testing Systemd. » 2023-10-13 23:31:30
Hello:
Nice work ...
Thanks.
Best,
A.
#735 Re: Other Issues » Ustable and Testing Systemd. » 2023-10-13 20:15:39
Hello:
Send them to this page . . .
Against my better judgement (if I've ever had such a thing) with today being both Friday 13th. and a local bank holiday, I decided to insist with Distrowatch.
I'm posting it here so you can ...
No idea, just for the chuckles.
Make what you will of it.
My email:
--- snip ---
... not *one* of those files contain an init system.
They are standalone files to either handle systemd unit files in
non-systemd distributions or be used at compile time by other
packages.
This enables Debian packages which have 'Build-Depends: systemd' to
be built on Devuan systems ensuring a non-systemd systemctl emulation
is installed.
They are *shims* (if you will) that allow most Debian packages (for
the time being) to run without issues in Devuan.
--- snip ---
---
Their reply:
---
--- snip ---
Nobody said they do. As you can clearly see on our Devuan page, we list
the three init Software packages Devuan supports (runit, OpenRC, and
SysV), we do not list systemd.
--- snip ---
You seem to be the only one confused by this. systemd packages are
available in Devuan, it offers systemd libraries and packages. We
therefore list systemd as being in the repositories, because it's there.
Nowhere do we claim Devuan uses systemd init.
---
As anyone can see, systemd (254.5) is listed as an available package in both Unstable and Testing in their Devuan page.
So much for that then.
No sense flogging a dead horse, is there?
A.
#736 Re: Other Issues » Ustable and Testing Systemd. » 2023-10-12 21:25:07
Hello:
Perhaps someone from the Devuan Team ...
Not on any Devuan team, not a dev/maintainer/packager either.
Nevertheless, I sent the people at Distrowatch an email.
--- snip ---
... Devuan does *not* use systemd as its init software in *any* of its versions/releases.
Devuan is Debian *without* systemd.
You may want to consider fixing that as it can lead to confusion.
Thanks in advance
--- snip ---
Here's their reply:
---
Devuan does not ship systemd as the _default_ init system. It still
includes the package in its repositories, which is what we show in our
package table.
---
Right ...
Then I wrote back with a link to the Devuan Package Information page with a query* for the systemd package and an email** address where they could write and ask for confirmation to what I was saying, I got this (interesting) reply:
---
The systemd packages are not only in the repositories, you can see them
on the Devuan package query page here:
https://pkginfo.devuan.org/cgi-bin/poli … *&x=submit
As you can see, our information is correct and systemd is in the main
Devuan repositories.
---
* https://pkginfo.devuan.org/cgi-bin/poli … d&x=submit
** freedom at devuan.org
I was about to write back with an explanation about the difference between the systemd package and all those files/packages named abc-systemd, systemd-xyz, abc-systemd-xyz (and so on) but decided that it was really not worth the effort.
But that's on me, I've never suffered fools lightly and too old to start now.
That said, I have not seen/found which page of the Repology site says anything about Devuan and systemd so I did not address the matter with them.
Best,
A.
#737 Re: Other Issues » Ustable and Testing Systemd. » 2023-10-12 12:02:37
Hello:
Distrowatch is a site that many, including myself, consult ...
There must be something wrong with whatever generates that list.
There's no systemd package in devuan.
I think that settles the matter, right?
A.
#738 Re: Other Issues » Ustable and Testing Systemd. » 2023-10-11 10:20:24
Hello:
I see that both Unstable and Testing have OpenRC, runit, SysV under "Feature" -> "Init Software".
systemd is not a listed option.
That said, I also see it is listed as in the "Package" column but systemd is not an available package in the Devuan repositories.
There would seem to be a discrepancy in the Distrowatch page.
Either that or, being Testing/Unstable releases, the package is there as a place holder and not used.
Not a dev/maintainer so I cannot say much more.
Have you tried setting up "Testing" or "Unstable" to check is systemd is effectively used?
Best,
A.
#739 Re: News & Announcements » Gnome vulnerability found » 2023-10-10 21:41:59
Hello:
... article link and a bit of information...
Yes, sorry about that.
Posted in a hurry.
Too much eye candy = fisher price ugliness.
I'd say needless eye candy+associated bloat = lack of Linux sense.
There's plenty of MS stuff for that.
A.
#740 News & Announcements » Gnome vulnerability found » 2023-10-10 16:27:28
- Altoid
- Replies: 6
Hello:
Just a heads-up.
Found this at The Register this morning:
Researcher bags two-for-one deal on Linux bugs while probing GNOME component
One-click exploit could potentially affect most major distros.
Wouldn't ever use Gnome but some people do.
libcue2 is present in the Devuan repositories and in my box because of audacious-plugins.
~$ apt list | grep libcue
libcue-dev/oldoldstable 2.2.1-2 amd64
libcue-dev/oldoldstable 2.2.1-2 i386
libcue2/oldoldstable,now 2.2.1-2 amd64 [installed,automatic]
libcue2/oldoldstable 2.2.1-2 i386
~$ Should get fixed soon.
Best,
A.
#741 Re: Other Issues » Ustable and Testing Systemd. » 2023-10-10 10:19:34
Hello:
... both Unstable and Testing are working on systemd, according to Distrowatch ...
... what is going on?
Could you please provide a link to the page where Distrowatch published that?
I cannot find it.
Thanks in advance.
A.
#742 Re: Installation » [SOLVED] Strange filemanager behaviour » 2023-10-07 14:53:08
Hello:
... data on separate partitions, even on another ssd.
... mounted through fstab in /home/$USER/local/ ...
I've thought about something similar.
But decided it was a better option to make back-ups via backintime and then back those up via rsync to a recovered WD-MBLive running on OpenWRT.
Worked quite well till it didn't and stopped using it.
Fortunately, files were not lost but I now have to see how to avoid it happening again.
... a bit chatty today...
Not at all, thanks for your input.
Best,
A.
#743 Re: Installation » [SOLVED] Strange filemanager behaviour » 2023-10-06 17:01:33
... updatedb ran when the filesystem was not mounted ...
Right.
Which is why the files ended up hiding when updatedb ran with the usually unmounted FS and showed up again if/when when I happened to run updatedb whith the FS mounted.
Hmm ...
I have come to think that Murphy works in mysterious ways ... 8^°'
Thanks for your input.
Best,
A.
#744 Re: Installation » [SOLVED] Strange filemanager behaviour » 2023-10-06 09:39:37
Hello:
One way ...
... would be to rsync /DATA to /media/storage/ when nothing is mounted at /media/storage.
... when you do mount something there, it will hide /media/storage/DATA.
I see.
That could have easily happened.
... 'locate' shows you what it found the last time updatedb ...
Yes.
But the locate result came up repeatedly, seems that it could find the hidden files.
Which is the reason I set out to see where they were.
Thanks for your input.
Best,
A.
#745 Re: Installation » [SOLVED] Strange filemanager behaviour » 2023-10-05 17:07:09
Hello:
Thank you for the prompt reply.
Much appreciated.
... what fstab says may be a red herring.
I see.
... the mount point is a directory in your root filesystem, and some files and directories have been moved into there when the /media/storage filesystem is not mounted.
Hmm ...
So fstab was not working properly?
... I suggest:
Done.
I then copied everything back to where it should have been ie: /media/storage/DATA and after checking everything was in place, deleted /media/storage2.
I was in a very ugly mood for the longest while when I "lost" all those files, so many thanks for this.
I've had to get at data buried under a mount point ...
But why did this happen?
It was (undoubtedly) of my own doing but I cannot imagine what I did.
I would like to avoid going through this again.
Thanks in advance.
Best,
A.
#746 Installation » [SOLVED] Strange filemanager behaviour » 2023-10-05 15:30:28
- Altoid
- Replies: 8
Hello:
I have come across something I am at odds with and don't understand.
I have a drive where I store data and has this fstab entry:
# -------------------------------------------------------------------------------------
#
# not automatically mounted - root only
# storage repository in 300Gb SAS s/n JHX71JDC
# was LABEL=storage /media ext4 defaults,auto 0 2
UUID=74649bbb-7fb9-46bc-990a-d3d96dd92dd9 /media/storage ext4 nouser,noauto 0 2
#
# -------------------------------------------------------------------------------------
Early on, I went from defaults,auto 0 2 to nouser,noauto 0 2 so that is would not be mounted at all times, only when I needed to access it.
The thing is that if I want to mount it, I get the usual "Authenticate" pop-up asking for my password and once entered, I see what I think is the content.
ie:
/media/storage -> 9 folders + 9 files
Total count: 8817 files
Size on disk: 14.2Gib
Some time ago, I lost a great deal of files to a misconfigured rsync ... ... or so I thought.
Today I accidentally stumbled (via locate) on one of those files, stored in /media/storage/DATA, one of the folders I thought was long gone along with its content.
So I fired up PCMan, had a look but it was nowhere to be seen.
ie: it was not one of the 9 folders under /media/storage.
I entered /media/storage/DATA in the PCMan address bar only to get a pop-up which informed me that it was not a valid directory.
On a hunch, I unmounted the /media/storage volume in PCMan, entered /media/storage/DATA in the address bar and there it was.
Not only that: all the files I thought I had lost were there.
I think there is some sort of permission problem at hand, no idea how this happened.
When I select all the files ie: /media/storage -> 9 folders + 9 files and select properties, the Owner and Group fields are blank.
In Access Control, view content is blank and Change content reads Only owner.
In /media/storage/DATA the Owner and Group fields read root (grayed out).
In Access Control, view content is reads Anyone Change content reads Only owner.
I don't understand what is going on.
I always thought that if fstab read nouser,noauto that was it.
ie: access did not depend on the ownership of the files it contained, just on being admin/root.
What am I missing?
Most importantly, how can I fix this?
Thanks in advance.
Best,
A.
#747 Re: News & Announcements » Linux security hole - The Register » 2023-10-05 13:09:48
Hello:
... already released through the security repos a day before the article.
See?
No time at all. 8^P
Cheers,
A.
#748 News & Announcements » Linux security hole - The Register » 2023-10-05 02:40:38
- Altoid
- Replies: 2
Hello:
This appeared on The Register tonight:
-----------------------------------------------------------------------------------------------------
Make-me-root 'Looney Tunables' security hole on Linux needs your attention
By Thomas Claburn - Wed 4 Oct 2023 // 21:27 UTC
https://www.theregister.com/2023/10/04/ … ables_bug/
-----------------------------------------------------------------------------------------------------
... a security hole that can be fairly easily exploited by rogue users, intruders, and malicious software to gain root access ...
... a buffer overflow vulnerability in the GNU C Library's handling of an environmental variable ...
... arises from the GNU C Library's dynamic loader (ld.so) mishandling of the GLIBC_TUNABLES environmental variable.
As usual. we'll see a patch/fix in no time at all.
Best,
A.
#749 News & Announcements » X.Org Security Advisory: Issues in libX11 prior to 1.8.7 & libXpm » 2023-10-03 18:32:05
- Altoid
- Replies: 0
Hello:
Just got this in my inbox.
Good to see that things 'X11' are rolling along steadily.
Best,
A.
***********************************************************************************
X.Org Security Advisory: October 3, 2023
Issues in libX11 prior to 1.8.7 & libXpm prior to 3.5.17
========================================================
Multiple issues have been found in the libX11 & libXpm libraries published
by X.Org for which we are releasing security fixes in libX11 1.8.7 &
libXpm 3.5.17.
The first issue (CVE-2023-43785) can be triggered by connecting to an
X server that sends specially crafted replies to X11 protocol requests.
The other 4 issues can be triggered by opening specially crafted XPM format
image files via libXpm. Two of the four issues have root causes in the
libX11 library and are fixed there, but patches have also been applied
to libXpm to avoid passing the invalid data to libX11 in the first place.
----------------------------------------------------------------------------
1) CVE-2023-43785 libX11: out-of-bounds memory access in _XkbReadKeySyms()
Introduced in: X11R6.1 [released March 1996]
Fixed in: libX11 1.8.7
Found by: Gregory James DUCK
Fixed by: Alan Coopersmith of Oracle Solaris Engineering
When libX11 is processing the reply from the X server to the XkbGetMap
request, if it detected the number of symbols in the new map was less
than the size of the buffer it had allocated, it always added room for
128 more symbols, instead of the actual size needed. While the
_XkbReadBufferCopyKeySyms() helper function returned an error if asked
to copy more keysyms into the buffer than there was space allocated for,
the caller never checked for an error and assumed the full set of keysyms
was copied into the buffer and could then try to read out of bounds when
accessing the buffer. libX11 1.8.7 has been patched to both fix the size
allocated and check for error returns from _XkbReadBufferCopyKeySyms().
Fix:
https://gitlab.freedesktop.org/xorg/lib … 78a3358a7f
2) CVE-2023-43786 libX11: stack exhaustion from infinite recursion
in PutSubImage()
Introduced in: X11R2 [released Feb. 1988]
Fixed in: libX11 1.8.7
Found by: Yair Mizrahi of the JFrog Vulnerability Research team
Fixed by: Alan Coopersmith of Oracle Solaris Engineering
When splitting a single line of pixels into chunks that fit in a single
request (not using the BIG-REQUESTS extension) to send to the X server,
the code did not take into account the number of bits per pixel, so would
just loop forever finding it needed to send more pixels than fit in the
given request size and not breaking them down into a small enough chunk to
fit. An XPM file was provided that triggered this bug when loaded via
libXpm's XpmReadFileToPixmap() function, which in turn calls XPutImage()
and hit this bug.
Further hardening to prevent similar bugs was done in libX11 by making
XPutImage() clip images to the maximum X protocol pixmap size (limited
by the use of unsigned 16-bit integers for height & width) when writing
to X pixmaps, and by making XCreatePixmap() generate X errors if a
height or width was specified that did not fit into an unsigned 16-bit
integer. In libXpm, hardening was done to return error codes for any
call that would have passed out-of-bounds width or height values to
XCreatePixmap().
Fix:
https://gitlab.freedesktop.org/xorg/lib … 536e863a86
Hardening:
https://gitlab.freedesktop.org/xorg/lib … 0f442ddf4a
https://gitlab.freedesktop.org/xorg/lib … 0b9b48784b
https://gitlab.freedesktop.org/xorg/lib … c31a50701c
3) CVE-2023-43787 libX11: integer overflow in XCreateImage() leading to
a heap overflow
Introduced in: X11R2 [released Feb. 1988]
Fixed in: libX11 1.8.7
Found by: Yair Mizrahi of the JFrog Vulnerability Research team
Fixed by: Yair Mizrahi of the JFrog Vulnerability Research team
When creating an image, there was no validation that the multiplication
of the caller-provided width by the visual's bits_per_pixel did not
overflow and thus result in the allocation of a buffer too small to hold
the data that would be copied into it. An XPM file was provided that
triggered this bug when loaded via libXpm's XpmReadFileToPixmap() function,
which in turn calls XCreateImage() and hit this bug.
Further hardening to prevent similar bugs was done in libXpm to return
error codes for any call to XCreateImage() that would have resulted in
this calculation overflowing.
Fix:
https://gitlab.freedesktop.org/xorg/lib … 9907aea6a0
Hardening:
https://gitlab.freedesktop.org/xorg/lib … 6da02e911e
4) CVE-2023-43788 libXpm: out of bounds read in XpmCreateXpmImageFromBuffer()
Introduced in: unknown - prior to xpm-3.4k [released 1998]
Fixed in: libXpm 3.5.17
Found by: Alan Coopersmith of Oracle Solaris Engineering
Fixed by: Alan Coopersmith of Oracle Solaris Engineering
When the test case for CVE-2022-46285 (fixed in libXpm 3.5.15) was run
with the Address Sanitizer enabled, it found an out-of-bounds read in
ParseComment() when reading from a memory buffer instead of a file, as
it continued to look for the closing comment marker past the end of the
buffer.
Fix:
https://gitlab.freedesktop.org/xorg/lib … f139ed67e0
5) CVE-2023-43789 libXpm: out of bounds read on XPM with corrupted colormap
Introduced in: unknown - prior to xpm-3.4k [released 1998]
Fixed in: libXpm 3.5.17
Found by: Alan Coopersmith of Oracle Solaris Engineering
Fixed by: Alan Coopersmith of Oracle Solaris Engineering
Fuzzing with clang's -fsanitize/libfuzzer generated an XPM file with a
corrupted colormap section which caused libXpm to read out of bounds.
Fix:
https://gitlab.freedesktop.org/xorg/lib … bc3fcd8f51
----------------------------------------------------------------------------
X.Org thanks all of those who reported and fixed these issues, and those
who helped with the review and release of this advisory and these fixes.
The X.Org security team would like to take this opportunity to remind X client
authors that current best practices suggest separating code that requires
privileges from the GUI, to reduce the risk of issues like CVE-2023-43785.
--
-Alan Coopersmith- alan.coopersmith@oracle.com
X.Org Security Response Team - xorg-security@lists.x.org
--
-Alan Coopersmith- alan.coopersmith@oracle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
#750 Re: Other Issues » deb package installation issue » 2023-10-02 02:26:33
Hello:
... su to root ...
From Chimaera Release notes:
https://files.devuan.org/devuan_chimaer … _notes.txt
su
The behaviour of su changed in Devuan 3 Beowulf. These changes persist
in Devuan 4 Chimaera. Use su - to get root's path or use the full path
to commands if you use only su. See the following for more information:https://www.debian.org/releases/buster/ … -variables -
https://wiki.debian.org/NewInBuster -
https://bugs.debian.org/905564
A.
Board footer
