SliTaz Forum

tcll

Member

Registered: 2026-01-25

Posts: 31

startx seems a bit too simple to be reliable

finally, a thread I can make here

so after working to make openbox into an appimage to attemt to remove [c]startup-notification[/c], [c]libSM[/c], and [c]libICE[/c] from the system, I happened to notice that configuring the standard [c]/etc/X11/xinit/xinitrc[/c] wasn't running my appimage as configured, so I took a gander at why starting from the root at [c]/usr/bin/startx[/c] and was rather surprised to find it just loads [c]$HOME/.xsession[/c] at that...

... are you TRYING to be insecure man? XD

I mean sure it's just userspace, but still like, anything executable in [c]~/[/c] is a security risk

(yes I know about [c]~/.profile[/c] also setting up [c]~/.local/bin[/c] which is a hacker's wet dream to compromise a system by)

I really hope these poor security practices ONLY apply to userspace and not the kernel itself

(if this OS really is used for routers like I'm told, then userspace is a non-issue as it should be removed anyways)

but anyways, you should really employ some of the safety practices in startx such as where xinit was used

(I've completely replaced xinit in my appimage with pkill ensuring everything terminates cleanly)

at least I can give credit for not using xauth, but running [c]Xorg[/c] without [c]-nolisten tcp[/c] really puts userspace at risk of remote usage

(+1 for being as direct as possible btw, I bashed my head against brick for months to figure that out for my appimage)

also btw, minor annoyance with the fact you can't run xorg on both TTY1 and TTY2 at the same time

(my xorg appimage beats you there, lol) ;D

I use that for testing if things will still function across multiple WMs when I remove system libs without having to terminate Xorg on TTY1

also one last thing...

why does xorg need glib2 to run? :vomit:

I've at least managed to remove dbus, but glib2? really? XP

(unless that's just openbox where it appears as xorg which can be excused, since at least you use libevdev which is awesome, rather than libinput which uses glib for wacom support for some insane reason)

... I guess we'll find out when I turn openbox into an appimage... lol

tcll

Member

Registered: 2026-01-25

Posts: 31

Re: startx seems a bit too simple to be reliable

alright I've validated

if it helps improve anything at all, here's mine

it's a standard [c]startx[/c] implementation modified to be an AppRun while removing most bloat like [c]grep[/c], [c]sed[/c], [c]hostname[/c], [c]xinit[/c] (credit to sx https://github.com/Earnestly/sx ), and anything else I could figure out...

(I should really remove the [c]$HOME[/c] stuff as well and reduce [c]$PATH[/c] and [c]$LD_LIBRARY_PATH[/c])

but this might help fill in a bunch of blanks for yours

EDIT: be sure to look through it thoroughly, I can tell you it's not malware, but obviously word of mouth doesn't generally mean anything until you actually see for yourself... XD

tcll

Member

Registered: 2026-01-25

Posts: 31

Re: startx seems a bit too simple to be reliable

neat little update

I've managed to get openbox removed from my system while booting into it as an appimage

but for some reason, the ~/.xsession startup just stopped running entirely where even restoring it to it's original contents no longer runs after it ran previously...

so I just flipped the table and ran Xorg directly from the TTY which worked

but here's what's neat

normally with my startx AppRun, I only get 1 log

[c]startx &> output.log[/c]

(this is why I couldn't tell if Xorg itself required glib2 or not)

but doing things the way I'm currently doing, I can now have 2:

[c]Xorg &> Xoutput.log & <programpath>/openbox/AppRun &> oboutput.log[/c]

so now I can actually see what requires what removed lib

note that Xoutput.log is different from Xorg.0.log

tcll

Member

Registered: 2026-01-25

Posts: 31

Re: startx seems a bit too simple to be reliable

it has now been fully verified

Xorg itself for some reason requires libglib-2.0.so.0

which is weird because it shouldn't have any dependency on Gnome garbage, especially something like glib2 which aims to break all software portability

willing to bet it's one of the extensions being the cause...

just like the libinput extension was the cause in my xorg appimage requiring glib

tcll

Member

Registered: 2026-01-25

Posts: 31

Re: startx seems a bit too simple to be reliable

I think I may have found the source of that problem via an strace on Xorg

it seems somewhere along the lines, xorg loads harfbuzz which depends on glib (could be from libpng)

I also checked udev just in case (another thing I'm working on removing once I figure out direct mouse access (NICs are also an issue, but I don't need to worry about that here)), but that only depends on glib-dev, which shouldn't have an issue if glib is removed

at least it's not Xorg itself that loads glib

tcll

Member

Registered: 2026-01-25

Posts: 31

Re: startx seems a bit too simple to be reliable

heh, crap just keeps happening XD

> minor annoyance with the fact you can't run xorg on both TTY1 and TTY2 at the same time

I've managed to get somewhere around 80% complete being able to do this

[c]Xorg -nolisten tcp :0 &> Xoutput.log & <programpath>/openbox/AppRun &> oboutput.log[/c] on TTY1

works just fine, but

[c]Xorg -nolisten tcp :1 vt2 &> Xoutput2.log & <programpath>/openbox/AppRun &> oboutput2.log[/c] on TTY2

while Xorg starts just fine, openbox seems to think it's already running on display 0 and leaves me on a black screen

(there should be a [c]-keeptty[/c] as well after [c]vt2[/c], but that completely locks up my system when I use it, otherwise TTY2 locks up when I exit xorg)

tcll

Member

Registered: 2026-01-25

Posts: 31

Re: startx seems a bit too simple to be reliable

hey Shann, I just wanna reinforce

please don't feel like I'm attacking you or your distro by how I'm coming off, I'm not at all, I'm just experienced

maybe not the MOST experienced, but certainly above average in running the smallest and most secure userspace possible XD

(would be cool of Linux had a HIPS that could protect userspace even further by monitoring and warning about critical syscalls before they execute (something WinXP had back in 2008 with Comodo))

^ something I've been talking about since 2013 that nobody wants to acknowledge is good for everyone

but seriously, I love SliTaz for how small it is, and how much effort (at least from what I've heard) you've put into securing the kernel and a lot of the packages

just cause I'm working on having a running kernel after what's basically a meticulous [c]sudo rm -rf /[/c] doesn't mean your distro sucks

shann

Administrator

Registered: 2011-04-01

Posts: 1,294

Re: startx seems a bit too simple to be reliable

Hi tcll,

No problem, sure you are direct.

Infact i know we need improvements again, try to do it step by step.

For Xorg, seem on rolling listen on tcp by default, think better to disable it.

Concerning extra depends of glib/harfbuzz, maybe added by mistake or other packages need it.

tcll

Member

Registered: 2026-01-25

Posts: 31

Re: startx seems a bit too simple to be reliable

> try to do it step by step.

yeah absolutely, get to these things whenever you feel it right, I'm really just listing off a bunch of stuff

I'm still learning here as well, in fact I have actually successfully removed udev already on the machine I'm talking to you from, but couldn't stick to it without a mouse or NICs (more research needed to add those), and am kinda stuck currently until I can remove OpenRC

for the mouse (without udev), I HAVE already tried the trick:

[c]mknod /dev/input/mice c 13 63[/c]

but for some reason xorg still ran keyboard-only (this is still unexplored territory for me)

but anyways, yeah

> Concerning extra depends of glib/harfbuzz, maybe added by mistake or other packages need it.

there's still a bunch in the air which I'll figure out via an Xorg-direct appimage, but I don't think anything was added by mistake, I think there's more going on with deps...

there IS a way to run Xorg headless to hopefully mitigate those deps as well, but that's another unexplored territory for me atm

I'm sure you could probably look into that, would be cool to see a minimized xorg without any need for stuff like libpng or the like, heck I wonder how much it compares with my Artix appimage as is XD

(side note, looks like I actually DO require glib in that as well, I could've sworn I'd removed that :eyes:)

[attachment=53761,3818]

tcll

Member

Registered: 2026-01-25

Posts: 31

Re: startx seems a bit too simple to be reliable

> openbox seems to think it's already running on display 0 and leaves me on a black screen

I got it, was missing the most simplest thing XD

Xorg doesn't set [c]DISPLAY[/c] for you, you have to do that yourself

so instead of running:

[c]Xorg -nolisten tcp :1 vt2 &> Xoutput2.log & <programpath>/openbox/AppRun &> oboutput2.log[/c] on TTY2

you'd rather want to run:

[c]DISPLAY=":1"; Xorg -nolisten tcp $DISPLAY vt2 &> Xoutput2.log & <programpath>/openbox/AppRun &> oboutput2.log[/c] on TTY2

openbox now runs without issue on both TTY1 and TTY2

also TTY2 isn't exactly locked, it just doesn't update when you type (you can't see what you type, but it's there), but updates normally on stdout

tcll

Member

Registered: 2026-01-25

Posts: 31

Re: startx seems a bit too simple to be reliable

so update

I've been researching and pondering

[c]-nolisten unix[/c] may actually be better than [c]-nolisten local[/c]

the less I can rely on a mounted filesystem, the better

the only issue to resolve is what some people are saying with security concerns related to the abstract namespace

but if I know my Linux well enough, there SHOULD be ways to secure that

but even still from my current position, more research is needed, so I'll get back to you later on that for potentially securing SliTaz as well

tcll

Member

Registered: 2026-01-25

Posts: 31

Re: startx seems a bit too simple to be reliable

looks like Apparmor can be used to invalidate everyone's concerns and secure abstract unix sockets

http://manpages.ubuntu.com/manpages/wily/man5/apparmor.d.5.html

^ Ubuntu can't find that page for me sadly, but it works through proxies