I also just noticed that you never check if asprintf() failed.

I'm not sure the logic in _pam_xdg_close() is correct. You seem to always close the last session, right? So if I initiate session A and then initiate session B and then log out of session A it will remove the user directory that was created for, and is potentially being used by, session B, which is still active, while leaving the user directory that was used by session A and is now unused in place.

In D44011#1004814, @des wrote:

I'm not sure the logic in _pam_xdg_close() is correct. You seem to always close the last session, right? So if I initiate session A and then initiate session B and then log out of session A it will remove the user directory that was created for, and is potentially being used by, session B, which is still active, while leaving the user directory that was used by session A and is now unused in place.

No because the sessions aren't tied to a real session, this is just a count.
So :

• user login -> xdg_session.0 is created
• user login again -> xdg_session.1 is created
• 1st session close -> xdg_session.1 is deleted
• 2nd session close -> xdg_session.0 is delete and the user session directory.

Is the module name clash with sysutils/pam_xdg intentional? It creates a POLA violation on upgrade: /var/run/user/<uid> moves to /var/run/xdg/<uname>.

Sorry for being late to the party, but what's the point in

1. Rewriting it, since we have sysutils/pam_xdg?
2. Having it in base instead of port?

In D44011#1006994, @jbeich wrote:

Is the module name clash with sysutils/pam_xdg intentional? It creates a POLA violation on upgrade: /var/run/user/<uid> moves to /var/run/xdg/<uname>.

It's not really POLA on the directory as it's solved by a reboot, one cannot say the same thing about modules argument.

In D44011#1007029, @arrowd wrote:

Sorry for being late to the party, but what's the point in

1. Rewriting it, since we have sysutils/pam_xdg?
2. Having it in base instead of port?

Because I believe that any user should be able to install FreeBSD, pkg install sway drm-kmod, kldload <kmod> and start sway without having anything else to do.
On the rewrite while it's true that we could have import it to base, I find the code really hard to read with all the defines and wanted something simpler.

pkg install sway drm-kmod

At this point, the drm-kmod package could pull in the pam_xdg package. Until we move to pkgbase, the base updates are slow. An user usually have to wait for a new release to get the updated piece of base.

I find the code really hard to read with all the defines and wanted something simpler.

Maybe it could've been solved upstream.

Anyways, it is already committed, so let's see how it works out.