After years/decades this is gradually happening more, I need to start always saying, but people jumping into discussions ongoing for pages/hours/days/weeks on forums & chat need to go back and read. Many don't then end up in entire discussions full of confusion/misunderstanding, and personally explain entirely different things (not that you have yet, but many often get angry when they find out, and use that as a reason to quit.) I mentioned not using passwords, blank passwords, etc., multiple times for many posts and am now simplifying/optimizing terms, because people can see I replied so they need to read to sub-topic beginning. To do it, yes, you just press <ENTER>.

It doesn't respect it that way nor with minlen=0.

Thanks for the link.

However the link is broken in your post:

I recommend the web-browser addons that change text URLs to hypertext.

Of course, the post/thread title is misleading: it's about making users with passwords then having to delete them after the fact. That is not how classic Unix through Slackware stable to this day work (such as FreeBSD, despite having PAM, asks in installation at user setup whether you even want password authentication, then whether you want blank passwords, and your choices become default for future accounts.).

In addition, I discovered something insecure. On Slackware-stable, after you delete password, then try login, you must still get asked password, press <ENTER>. Now (on Slackware-current) you don't. To skip password, you used to have to edit /etc/passwd yourself and remove 'x' in place of password, which was there to make it seem as if there was password. Now anyone can immediately try an account they assume has password, but find out they're allowed to login with wrong password (even though the 'right' one isn't one.) Sure, I have some blank passwords, but that doesn't mean I don't want a password prompt for some/all!

It just happens that I've always used password for my users. So I don't have a clear understanding of how you create a user without a password or a blank password. And it seems that based on thread user without a password, what is important is how the absence of password or blank password is implemented in /etc/passwd.
At this point, I can no longer help on this issue. I don't have sufficient technical knowledge to improve on the proposed two-step approach (i.e. create user with password and then remove it with "passwd -d").

Hmm, that's strange. Maybe it is not at the stage when .xsession is evaluated. Could you try with the if statement from Robbys package to see if ck is loaded this way on your machine?

Greetings

Lioh

Seeing those "classic UNIX" diatribes, I can't help to not remember that "adduser" is not something inherited from the good old UNIX, but a tool written by Mr. Volkerding for Slackware. Yes, it is specific to Slackware.

However, from what I know the classic UNIX way to create users is "useradd", like elegantly it is used to create a system user right there:

https://slackbuilds.org/repository/1...work/hiawatha/

Yes, for creating system users with no password, it's more than enough.

Ok, done a little more digging.

Using xdm, with or without pam_ck_connector enabled, I don't get a DESKTOP_SESSION set. So, all the xsessions scripts that check for it being null will always try and start a ck-launch-session, even if ck_connector has already done it and it is unnecessary.

Perhaps the answer is to check XDG_SESSION_COOKIE in those xsession scripts instead, but I'm wondering how that will effect when those same scripts are run by startx given that consolekit is now also registering sessions for tty logins.

Perhaps the answer is just not to register ck sessions for tty logins.

Alternatively, maybe /etc/X11/xdm/Xsession should set DESKTOP_SESSION, but only if XDG_SESSION_COOKIE is already set.

This is starting to become a can of worms!

1 members found this post helpful.

The addition of "ck-launch-session" in the X init scripts in Slackware has been a necessity when PAM was not part of Slackware. See for instance my comment from 2017 here: https://bear.alienbase.nl/cgit/ktown...4e4866bbdf0636

I think we need to revisit these bits like

and just stick with "exec dbus-launch --exit-with-session"

1 members found this post helpful.

This sounds like a very good idea to me.

In this case consolekit is not started on my machine with -current using XDM and IceWM as a desktop. I am using unmodified PAM configs which have pam_ck_connector.so enabled for xdm.

Edit: sorry I have just seen that icewm has just

So I am going to try with dbus-launch only.

I can confirm that this works fine. consolekit is started correctly this way and things like Thunar gvfs access work fine.

Might be alright when someone does a startx and uses the same console as the tty ck session, but if one does something like a startx -- :8 vt8 & then that's essentially a new session and probably needs its own ck session. I suspect startx is just too primitive for modern X11 enviroments with all this consolekit, dbus, and what have you stuff.

Also, I'm not a fan of using dbus-launch like that: it's caused me problems in the past, so I always use the eval method of staring it.
... but that has to be done within the ck-session or many of the dbus services don't function properly.

It's a workaround, but the underlying issues are these:

xsession/xinitrc files are using DESKTOP_SESSION to determine whether they've been started by a display manager, or a startx, and then starting ck-launch-session depending on what's starting them, rather than on whether it needs starting

I think eric was right above, and xinitrc/xsession files shouldn't be launching console-kit sessions. Instead, the cleanest solution is to have startx, or the display manager do the ck-launch-session.

Then DESKTOP_SESSION can be used for its original purpose without misusing it to trigger side effects.

/etc/X11/xdm/Xsession still should be setting DESKTOP_SESSION, but that's not what should determine whether ck-launch-session is called or not.

1 members found this post helpful.

I agree with you, sometimes I have the impression that certain things are not enhanced, or not finished.

Hello,

In the case of XDM, this requires to apply the patch xdm-consolekit.patch.gz (that's ok), and to run 'autoreconf -vif' before the call of 'configure' which is currently not the case. This call was present when XDM has been upgraded to 1.1.12 (downgraded to 1.1.11 a short time after). See this thread, and more precisely the posts #14 (and #15) .

--
SeB