Opening a bug for this, as discussed with flameeyes. When starting a daemon with "start-stop-daemon --start --chuid ${USER}", the TMPDIR variable is not initialised. So any server application generating sockets (Emacs running in detached mode is an example) will create them under /tmp. On the other hand, the user's login session will have TMPDIR set, so any client started from it will look for the socket there.
What is responsible for setting TMPDIR and why do you think that has anything todo with start-stop-daemon?
Let me try to explain what the problem is and what the _solution_ is: Right now start-stop-daemon only uses the session PAM chain to set pam_limits.so where it applies (that is, not BSD since there isn't one there). Unfortunately this is suboptimal, since one might as well use pam_mktemp to create a private TMPDIR per each user and thus want the users' TMPDIR be set for all of them properly. Since mktemp is handled in pambase, the solution I propose is this: - I make a new release of pambase that creates a services pam.d file, which enables pam_limits on Linux PAM and pam_mktemp if the USE flag is enabled - $whoever makes a new release of openrc depending on the new pambase version (that I'm going to release in both EAPI1 and 2), that only includes the services stack for the session chain in pam.d/start-stop-daemon At that point the users can set up their system as they prefer. I don't know about SElinux but I think this approach will improve situation for that and audit too. Anybody has a problem with this approach?
Thanks for a proper explanation :) Just tell me the changes needed to start-stop-daemon.pam
Okay got the new release out, I called the pam.d file system-services since all but "others" entries in pambase are called system-*. For what concerns s-s-d, the pam.d file should be changed to use session include system-services instead of the pam_limits.so module for the session chain. Then make it RDEPEND on >=sys-auth/pambase-20081028 and unmask the pam USE flag on *BSD (after making sure it builds, but I think it does). Et voilà, we can extend it together with everything else through pambase.
There is one further change required in s-s-d so that it actually picks up the environment as changed by the session chain; will take care of it.
Okay git://git.flameeyes.eu/others/openrc.git has a patch to make sure that pam_mktemp is respected as needed. Roy can you check and merge that in?
I'm on base-system.
(In reply to comment #6) > Okay git://git.flameeyes.eu/others/openrc.git has a patch to make sure that > pam_mktemp is respected as needed. Roy can you check and merge that in? If the string pamenv does not contain a =, then surely we should *remove* the existing variable in env if brought across? Aside from that .... the style does not match, xstrdrup should be used over strdup and does pam_getenvlist really need an explicit cast?
I admit I took the good part of the code from shadow, feel free to change the style if you want. I don't think you have to remove the environment if the = sign is missing, login doesn't, at least.
When can we expect a new version of OpenRC with these changes?
I've pushed the patch to the OpenRC repo, thanks (In reply to comment #4) > For what concerns s-s-d, the pam.d file should be changed to use > > session include system-services > > instead of the pam_limits.so module for the session chain. I think the ebuild should be responsible for this as that sounds very Gentoo centric. Of course, I could always add a comment to the s-s-d.pam file for any mktemp foo if available.
(In reply to comment #10) > When can we expect a new version of OpenRC with these changes? Pretty soon. If not this weekend, then early next week. I'd like to get rc-status reporting hotplugged services instead of just wanging them in unassigned services. Speaking of hotplugged services, I'm 90% sure about changing the default to not allow hotplugging as I still get complaints about it. The ebuild can always change this if I decide to make the change.
Have fun, I was the first tester of _rebooting_ with this change, and I didn't like it! :P While this actually fixes orbit launch on /tmp, it breaks udev which makes it impossible to start up, funny, ain't it? :P The problem is that s-s-d tries to use pam for launching udevd, but since udevd is not started already, PAM cannot identify the unix session and thus cannot authenticate the user. So now the question is: should we add a --nopam option or what else?
How does pam authenticate the user session? I really don't want to add a --nopam option and would rather have the code fail gracefully inside s-s-d if at all possible.
Any news here? What is the status of this wrt to OpenRC and PAM?
(In reply to comment #15) > Any news here? > What is the status of this wrt to OpenRC and PAM? OpenRC-0.4.3 already has Diegos patch to s-s-d.c in I just tweaked it in my repo to unset variables without a = symbol as discussed above. I've not tested with the new s-s-d pam.d service files though. I'm not too hot with them to know what to change either. Happy to try and resolve any pam/udev issues though.
This one is fixed "sort-of", but fixed nonetheless.
