Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Following 11-11-2011 F16 updates I have following problem 99% certain this did not happen before the updates Login to the console as fred Create a konsole window [fred@naxos ~]$ xhost + access control disabled, clients can connect from any host [fred@naxos ~]$ su - ja Password: ja@naxos ~ 1$ export DISPLAY=:0.0 ja@naxos ~ 2$ gedit prob.txt ** (gedit:4544): CRITICAL **: unable to create '/run/user/fred/dconf'; dconf will not work properly. ja@naxos ~ 3$ Editing is possible but ja preferences are not honoured Why is gedit trying to create a file in fred's directory? [root@naxos ~]# ls -l /run/user/ total 0 drwx------. 4 fred fred 80 Nov 11 11:29 fred drwx------. 2 root root 40 Nov 11 12:00 root Fully updated F16 Using KDM and XFCE (not GDM or Gnome) [root@naxos ~]# yum info gconf* Installed Packages Name : GConf2 Arch : x86_64 Version : 3.2.3 Release : 1.fc16 Size : 6.2 M Repo : installed From repo : local-16-update Summary : A process-transparent configuration system URL : http://projects.gnome.org/gconf/ License : LGPLv2+ Description : GConf is a process-transparent configuration database API used to : store user preferences. It has pluggable backends and features to : support workgroup administration. [root@naxos ~]# yum info dconf Installed Packages Name : dconf Arch : x86_64 Version : 0.10.0 Release : 1.fc16 Size : 210 k Repo : installed From repo : anaconda-0 Summary : A configuration system URL : http://live.gnome.org/dconf License : LGPLv2+ Description : dconf is a low-level configuration system. Its main purpose is to provide a : backend to the GSettings API in GLib.
This is because su - does not change the XDG_RUNTIME_DIR environment variable. Setting XDG_RUNTIME_DIR=/run/user/ja is not going to solve the problem, since dconf relies on the system to create (and remove) the runtime dir. Unsetting XDG_RUNTIME_DIR will make dconf use ~/.cache, and thus avoid the problem.
Matthias, I am sorry, but I don't understand why you close this as 'NOTABUG'. So what you are essentially saying by doing this is that end users should not expect dconf to work after they did 'su -', and for what it's worth, I would find that assertion questionable. In other words, this ought to be fixed somehow, IMHO.
(In reply to comment #2) > Setting XDG_RUNTIME_DIR=/run/user/ja is not going to solve the problem, since > dconf relies on the system to create (and remove) the runtime dir. Then we have at least one of the following problem: - dconf shouldn't rely on the sytem to create the runtime dir - the sytem (systemd?) should create the runtime dir when loging in using "su -". I do need a working environnement when testing with my test user. Can you please re-open this bug ? Looks like I don't have the rights to do it.
I am tentatively re-opening the bug. I don't meant to be rude by doing this. It's just that I think we need at least some rationale of why this should be seen as an expected behaviour.
I guess this could also have been added to the release notes.
(In reply to comment #3) > Matthias, I am sorry, but I don't understand why you close this as 'NOTABUG'. > > So what you are essentially saying by doing this is that end users should not > expect dconf to work after they did 'su -', and for what it's worth, I would > find that assertion questionable. In other words, this ought to be fixed > somehow, IMHO. I closed it as NOTABUG because dconf is behaving as expected.
I see. So I guess this should be assigned to another component, then. Which component would this belong to? I am not sure.
Why doesn't dconf do a fall back on ~/.cache if XDG_RUNTIME_DIR is incorrect ?
I confirm that something has started going wrong in F16. On the earliest of my F16 (VPN) boxes, everytime I do gsettings there, I get: [root@box ~]# su - username [username@box ~]$ export DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-eQQWiB57Vt,guid=89efbb85dbd202c7c0d0a74d0000001f [username@box ~]$ gsettings list-recursively org.gnome.Vino ** (process:2599): CRITICAL **: unable to create '/run/user/root/dconf'; dconf will not work properly. org.gnome.Vino alternative-port uint16 5900 org.gnome.Vino authentication-methods ['none'] org.gnome.Vino disable-background false org.gnome.Vino disable-xdamage false org.gnome.Vino enabled false org.gnome.Vino icon-visibility 'client' org.gnome.Vino lock-screen-on-disconnect false org.gnome.Vino mailto '' org.gnome.Vino network-interface '' org.gnome.Vino prompt-enabled true org.gnome.Vino require-encryption false org.gnome.Vino use-alternative-port false org.gnome.Vino use-upnp false org.gnome.Vino view-only false org.gnome.Vino vnc-password 'keyring' Once I read through this bug description and comments I did: [username@box ~]$ echo $XDG_RUNTIME_DIR /run/user/root [username@box ~]$ XDG_RUNTIME_DIR=/run/user/username And voilà: [username@box ~]$ gsettings list-recursively org.gnome.Vino org.gnome.Vino alternative-port uint16 5900 org.gnome.Vino authentication-methods ['none'] org.gnome.Vino disable-background false org.gnome.Vino disable-xdamage false org.gnome.Vino enabled true org.gnome.Vino icon-visibility 'client' org.gnome.Vino lock-screen-on-disconnect false org.gnome.Vino mailto '' org.gnome.Vino network-interface '' org.gnome.Vino prompt-enabled false org.gnome.Vino require-encryption false org.gnome.Vino use-alternative-port false org.gnome.Vino use-upnp false org.gnome.Vino view-only false org.gnome.Vino vnc-password 'keyring' You can even see that some values are different between first and second listings (second surely for "username", but first? "root"?). Therefore, there surely is something wrong with settings XDG_RUNTIME_DIR. /run/user/username/dconf was created by the system as, after reading the comments, I assume it should be.
On a F15 boxes I get: [root@box ~]# echo $XDG_RUNTIME_DIR /run/user/root [root@box ~]# su - username [username@box ~]$ echo $XDG_RUNTIME_DIR /run/user/username [username@box ~]$ exit logout [root@box ~]# echo $XDG_RUNTIME_DIR /run/user/root [root@box ~]# su username [username@box root]$ echo $XDG_RUNTIME_DIR /run/user/username And on F16 boxes: [root@box ~]# echo $XDG_RUNTIME_DIR /run/user/root [root@box ~]# su - username [username@box ~]$ echo $XDG_RUNTIME_DIR /run/user/root [username@box ~]$ exit logout [root@box ~]# echo $XDG_RUNTIME_DIR /run/user/root [root@box ~]# su username [username@box root]$ echo $XDG_RUNTIME_DIR /run/user/root So something definitely changed in the way "su" works.
(In reply to comment #8) > I see. So I guess this should be assigned to another component, then. Which > component would this belong to? I am not sure. Since it is a problem with "su" and "su" belongs to "coreutils", I propose this should be reassigned to "coreutils" component. At the same time I would recommend changing the summary to something along the lines of '"su" fails to set XDG_RUNTIME_DIR in F16'. (In reply to comment #2) > This is because su - does not change the XDG_RUNTIME_DIR environment variable. That's exactly right. > Setting XDG_RUNTIME_DIR=/run/user/ja is not going to solve the problem, Yes it does - see comment #10. > since dconf relies on the system to create (and remove) the runtime dir. The proper runtime directory is created by the system, but "su" fails to set XDG_RUNTIME_DIR - see comment #10 and comment #11. ------------- OTOH - I would like to generalize Dodji Seketeli's notion in comment #5, to point to or give the rationale behind the change, if it is purposeful rather than a random "feature" addition.
Reading https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/Pam_systemd Systemd's pam module is supposed to create this directory when user logs in so I guess it should do it when loging in using 'su' as well. Should we re-assign to systemd then?
(In reply to comment #13) > Reading https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/Pam_systemd > Systemd's pam module is supposed to create this directory when user logs in so > I guess it should do it when loging in using 'su' as well. Should we re-assign > to systemd then? Please, do reassign this to systemd. Thank you. This certainly is the module to perform the needed actions. It still seems though, that the problem is with interfacing with "su", since the variable is properly set for the user to originally log in into the system (different use of PAM modules than when logging through GDM or SSH, maybe?). Scripting with "su -c" is also affected - checked it. Also, as previously mentioned (comment #12), the needed directory is actually created but the variable $XDG_RUNTIME_DIR is not set appropriately to point to it (it keeps pointing to where it did for the "su"-ing user, which is then unreadable for the logged-in-with-"su" user - hence the original reporter's problem with launching gedit which is a side-effect of it), it has to be set manually to make everything work properly again.
Reassigned to systemd
I can reproduce this. With the patch adding a debug print to pam_systemd ( http://cgit.freedesktop.org/systemd/commit/?id=ce9593140b127ce782e2fa2f47fc55558b331126) I am getting this when I do "su - michich" from root's shell: Dec 14 14:49:45 f16 su: pam_systemd(su-l:session): Asking logind to create session: uid=0 pid=1362 service=su-l type=tty seat= vtnr=0 tty=pts/0 display= remote=no remote_user=root remote_host= Dec 14 14:49:45 f16 su: pam_systemd(su-l:session): Reply from logind: id=3 object_path=/org/freedesktop/login1/session/3 runtime_path=/run/user/root session_fd=6 seat= vtnr=0 Dec 14 14:49:45 f16 su: pam_unix(su-l:session): session opened for user michich by root(uid=0)
(In reply to comment #16) > Dec 14 14:49:45 f16 su: pam_systemd(su-l:session): Asking logind to create > session: uid=0 [...] It got that uid from the loginuid. Calling pam_loginuid.so from /etc/pam.d/su-l would make this work, but I guess the purpose of loginuid is exactly not to be called from su...
Since it looks like the problem is at least with "su"'s interaction with the PAM module (if not an incorrect usage), it seems that maybe it would be slightly more fruitful to attract the attention of coreutils maintainers (CC? reassign? I guess they don't even know about this...). On a side note - the directory /run/user/username *might* not get created at the time of performing "su", since all the computers I tested this with are automatically logging in to username and are not logging out until the computer is shut down. As I understand, the directory is created right after first logging in and removed at the last logging out of a user, therefore its existence does nothing to trace the bug on my side. On a second side note - is it possible to change the title/summary to something more to the point (at least getting rid of "gedit" mention which has absolutely nothing to do with the actual problem).
Reassigning to coreutils and changing summary. Coreutil maintainer(s) see comment 16 and comment 17. Just reassign to systemd with feedback if this is something we should be solving on that end. Thanks
In reply to comment#11 - su pam support (which is added by downstream patch) changed quite a lot recently - we merged SUSE and RedHat pam support patch to consolidate these two distributions. However, there was one change in pam between F15 and F16 - trying to support ecryptfs mount of "Private" - #722323 . But even that change was not sufficient to make it working and probably was not correct. Anyway, adding Tomas Mraz to CC as he is more experienced with pam.
loginuid is original UID of the session and should not/may not be changed by su. Thus pam_systemd should not use loginuid for the purpose of setting XDG_RUNTIME_DIR.
This bug still exists in F17. It certainly seems to be a legitimate bug to me. I want user isolation for two users, alice and bob, but I want bob to be able to throw windows up on alice's display, and those x11 apps to work correctly. For example, alice allows bob access to her display: [alice@localhost] $ xhost +si:localuser:bob Somehow bob gets a login shell, in my instance specfic instance, root does: [root@localhost] # su -l bob Then bob exports his display to alice's desktop, local in this case, [bob@localhost] $ export DISPLAY=:0.0 and throws up a PDF [bob@localhost] $ evince misunderstanding-x11-fundamentals.pdf only to receive: ** (evince:9077): CRITICAL **: unable to create '/run/user/alice/dconf'; dconf will not work properly. (caveat, root was a bash login shell, su - by alice) though the PDF displays on alice's desktop, evince prefs are not saved at all. In reply to comment#21, seems to be that there is an issue with your statement. When su -luser, this is a login shell. Seems to me that loginuid should be changing at this point. In my opinion su should not be knowing or caring anything about XDG_RUNTIME_DIR, evar. (*cough* *cough* hack.) I don't care why app saving prefs (dconf) does not work but from a user perspective it seems intuitive that it should work and it doesn't.
(In reply to comment #22) > In reply to comment#21, seems to be that there is an issue with your > statement. When su -luser, this is a login shell. Seems to me that loginuid > should be changing at this point. Nope, the loginuid traces the UID of the original user account that was logged into the machine. This is really important for auditing who is the real user behind the operations on the different account.
As I understand it, the pam_loginuid is for auditing to tag a process with "original logger's UID from the authentication entry point". In the case of su, only the superusers don't have to authenticate themselves, so the purpose of the "thou shalt not pam_loginuid from su" is not really clear for me. Whatever was meant for pam_loginuid, the bottom line is that if someone gets root rights they can do anything - also save a password for some account, change this password, log in remotely as that account (it's an entry point, so the account becomes the "original logger"), do something bad or good, then log off, and change the password back. In the end, I propose pam_systemd should get the UID for the new user some other way and set the environment accordingly. This would let the discussion of whether (or when) su should run pam_loginuid be resolved by philosophers. PS. I was about to bump this in a couple of days as to not look too aggressive about it. I'm still waiting for this to be resolved. Even though I grew accustomed to it, entering "export XDG_RUNTIME_DIR=/run/user/*" every time I login to a remote machine to do anything that is connected with FreeDesktop specifications is really bothersome (especially that more and more is relying on those standards, which by itself is for the better).
(In reply to comment #23) > (In reply to comment #22) > > > In reply to comment#21, seems to be that there is an issue with your > > statement. When su -luser, this is a login shell. Seems to me that loginuid > > should be changing at this point. > > Nope, the loginuid traces the UID of the original user account that was > logged into the machine. This is really important for auditing who is the > real user behind the operations on the different account. Right. And additionally, with CONFIG_AUDIT_LOGINUID_IMMUTABLE enabled in the kernel, it is not even possible to change the loginuid of a process.
In reply to comment#23, You're not discussing, you're making categorical statements. "su -login user" is a perfectly legitimate login entry point as far as I'm concerned. "su user" is not. I understand the ramifications for auditing. In reply to comment#24, > In the end, I propose pam_systemd should get the UID for the new user > some other way and set the environment accordingly." I think you hit the nail on the head here. While it may be expedient, it doesn't seem to cover corner cases well; like multi-user X? In reply to comment#25, Your statement is counter intuitive. If loginuid "was supposed to be" immutable, there wouldn't be a need for a kernel config option. I notice how it mentions systemd in the Kconfig and that I'm guessing that it's systemd folks who wanted it in there. See point #2 above. Back to the point of my original post and comment#1's (and not arguing details and philosophy) bob's evince and ja's prefs should be saved correctly. This is a bug.
(In reply to comment #26) > If loginuid "was supposed to be" immutable, there wouldn't be a need for > a kernel config option. I notice how it mentions systemd in the Kconfig and > that I'm guessing that it's systemd folks who wanted it in there. The guess is wrong. The audit developers always wanted loginuid to be immutable, but only systemd made it possible to achieve in practice. That's when the config option was introduced: See http://www.redhat.com/archives/linux-audit/2011-November/msg00040.html: "Systemd has changed how userspace works and allowed us to make the kernel work the way it should."
(In reply to comment #26) > Back to the point of my original post and comment#1's (and not arguing > details and philosophy) bob's evince and ja's prefs should be saved > correctly. This is a bug. Perhaps. Does anyone have specific suggestions how a fix should look like?
I explicitly chose to bind this to loginuid rather than anything else. People shouldn't fool themselves in assuming that "su" would get them a completely new session that has all properties of the destination user rather than the source user. THis is technically not possible, and if it would be implemented would even kinda defeat the point of su. For example, people probably want DISPLAY= to be the old one so that their root program they started with su an run on X11. OTOH the home directory should probably be the one of the destination user afterwards, but the current directory the one of the source user. The audit trail should be the one of the old user, but $PATH of the new user. And so on and so on. So people want a weird mix of things from the old and the new user session, and even worse, people want different things from the old and from the new session. For example, PA now places its socket in XDG_RUNTIME_DIR, and so does dconf. But apparently this bug report is a complaint that dconf should be the one of the new user. THis would break audio of however, which probably should be the one of the original user. So, we should not pretend we could make "su" work properly for the general case, or that we could find a way that makes this work for everybody. When we decided to base our systemd XDG_RUNTIME_DIR logic on the audit login session id (if it is available) is the thinking that "su" should be minimal in its effect, and almost everything that is not explicitly detached from the old session should continue to be from the old session. i.e. the default should be not to detach rather than to detach. If you want a fully detached text session then use "ssh localhost" or so, which virtualizes everything. So really, I see little to fix here in systemd. I believe basing this on loginuid is the right thing. And if the trade-off is between breaking PA and breaking dconf my choice is to stick to what makes sense on logical level.
(In reply to comment #29) > So, we should not pretend we could make "su" work properly for the general > case, or that we could find a way that makes this work for everybody. > So for a sysadmin, I need to be able to run commands as other users. For years "su - username" has provided this. How can I accomplish if "su" doesn't work anymore?
(In reply to comment #30) > (In reply to comment #29) > > So, we should not pretend we could make "su" work properly for the general > > case, or that we could find a way that makes this work for everybody. > > > > So for a sysadmin, I need to be able to run commands as other users. For > years "su - username" has provided this. How can I accomplish if "su" > doesn't work anymore? Well running X11 apps via su has always been half-broken (D-Bus!), and it continues be half-broken. gedit just won't save its settings, and that's it.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Based on comment 29 I'm closing this as notabug feel free to reopen and move to rawhide if you still believe this is incorrect behaviour. Thanks
Finally finding some time to get back to writing here - yes, I do think it is incorrect behaviour. Shortly: If you really feel the need to keep "su" clean, I propose, to resolve this, additional PAM modules that could be attached to "su" and "su-l" events through configuration. Back to discussion: I see most critical issues in following situations: - systems where you cannot install things like ssh - any way to achieve the same result as earlier anymore? - quite obvious information leak - how can one create a clean environment e.g. for a temporary server than communicates with outside world, with a script now? Especially using a user that has a nologin shell? (In reply to comment #31) > gedit just won't save its settings, and that's it. Way to show scorn! Eristic classes maybe? It is not "oh, it's just gedit" - almost everything now uses gconf / dconf for settings (and otherwise), including practically all of the GUI and also some command-line tools. It breaks old scripts - simple use of gsettings does not work either as was already shown. Combining this fact with little information about what environment variables programs use (look those up e.g. for gedit while it's mentioned) means we're back to the "diagnose a not working black box" tile. (In reply to comment #29) > People shouldn't fool themselves in assuming that "su" would get them a > completely new session that has all properties of the destination user > rather than the source user. THis is technically not possible, and if it > would be implemented would even kinda defeat the point of su. This is wrong from the starting point - *YOU* don't want people get a completely new session. If it was impossible I wouldn't become myself after ssh'ing into a server but rather some mutilated root offspring, because that's what's running the server daemon. I see no reason to not let people get exactly what ssh is giving them (auditing? - read on). Also, why would it "kinda defeat the point of su"? What is THE point of su? If you would be so kind to enlighten me. > OTOH the home directory should probably be the one of the destination user > afterwards, but the current directory the one of the source user. Isn't this was is happening now? > The audit trail should be the > one of the old user, but $PATH of the new user. And so on and so on. This idea of auditing is coarse-grained. Finer auditing could be made through permanent process parent tagging (PPPID, different from casual PPID) - if a process was forked off some other it is permanently tagged as it's child even if it forks and PPID changes to 1. The PPPID would disappear only when all of its forks die. If such auditing was implemented there would be no reason to keep and secure explicit loginuid since it's equivalent could be derived from the permanent-process-parent chain. What I wouldn't give to have SUCH auditing - many times have I wondered what other process forked off a process that is now PPID 1. This idea is also quite similar to CGroups which are already implemented, so it might not have to be written from scratch. > So people want a weird mix of things from the old and the new user session, > and even worse, people want different things from the old and from the new > session. For example, PA now places its socket in XDG_RUNTIME_DIR, and so > does dconf. But apparently this bug report is a complaint that dconf should > be the one of the new user. THis would break audio of however, which > probably should be the one of the original user. If it's like that, it won't work anyway, because most new sessions don't have appropriate rights to interact with an old session's socket! Quit thinking "su" is used only for getting super-user rights. Even the first example in this bug report is otherwise. > So, we should not pretend we could make "su" work properly for the general > case, or that we could find a way that makes this work for everybody. Once again - have you identified THE general case? I say, general case is generalising individual cases. How is it then that the *previous* "general case" worked fine with everyone? Please, if the idea ain't broken, don't fix it. And we should by all means try to make "su" do the most - it's all about getting most of automatisation! Setting even a few variables every single time one is logging in isn't really getting along with the DRY principle, does it? > When we decided to base our systemd XDG_RUNTIME_DIR logic on the audit login > session id (if it is available) is the thinking that "su" should be minimal > in its effect, and almost everything that is not explicitly detached from > the old session should continue to be from the old session. i.e. the default > should be not to detach rather than to detach. So maybe create some additional PAM modules based on people's needs and therefore those could be easily detached and attached? > If you want a fully detached text session then use "ssh localhost" or so, > which virtualizes everything. This is not always applicable, especially in the world of embeded.
(In reply to comment #29) > I explicitly chose to bind this to loginuid rather than anything else. > People shouldn't fool themselves in assuming that "su" would get them a > completely new session that has all properties of the destination user > rather than the source user. THis is technically not possible, and if it > would be implemented would even kinda defeat the point of su. > > For example, people probably want DISPLAY= to be the old one so that their > root program they started with su an run on X11. OTOH the home directory > should probably be the one of the destination user afterwards, but the > current directory the one of the source user. The audit trail should be the > one of the old user, but $PATH of the new user. And so on and so on. > > So people want a weird mix of things from the old and the new user session, > and even worse, people want different things from the old and from the new > session. For example, PA now places its socket in XDG_RUNTIME_DIR, and so > does dconf. But apparently this bug report is a complaint that dconf should > be the one of the new user. THis would break audio of however, which > probably should be the one of the original user. > > So, we should not pretend we could make "su" work properly for the general > case, or that we could find a way that makes this work for everybody. > > When we decided to base our systemd XDG_RUNTIME_DIR logic on the audit login > session id (if it is available) is the thinking that "su" should be minimal > in its effect, and almost everything that is not explicitly detached from > the old session should continue to be from the old session. i.e. the default > should be not to detach rather than to detach. > > If you want a fully detached text session then use "ssh localhost" or so, > which virtualizes everything. > > So really, I see little to fix here in systemd. I believe basing this on > loginuid is the right thing. And if the trade-off is between breaking PA and > breaking dconf my choice is to stick to what makes sense on logical level. This statement is definitely right for "su". However for "su -" case I would expect that XDG_* directories are created with uid of destination user. To accomplish this I think two changes need to be done: 1. Change "session" part of /etc/pam.d/su (i.e. "su" variant) to session optional pam_keyinit.so revoke session required pam_limits.so session required pam_unix.so The main reason behind this is that "su" should just borrow uid and all environment variables (with some exceptions - $HOME, $SHELL, $USER, $LOGNAME, $PATH, and $IFS, not sure if others) should be preserved. This is also true for XDG_ variables. Another reason for this change is to avoid calling pam_systemd for non-login shell. 2. Change pam_systemd to create & set XDG_ directories with UID of target user, not of the loginuid user. After those two changes, "su" will just borrow uid of new user but "su -" will create new session, including XDG_ directories. Note there might be needed even more sophisticated pam.d/* change to keep "runuser", which is just variant of "su", in sync with "su" so /etc/pam.d/su might look like ... session include runuser ... and all changes will go into /etc/pam.d/runuser. Ditto for /etc/pam.d/su-l and /etc/pam.d/runuser-l. Also please note there might be needed separate patch for dconf to fall back to ~/.cache when XDG_RUNTIME_DIR is not accessible, which should happen in "su" case. What do you think about this proposal?
*** Bug 915498 has been marked as a duplicate of this bug. ***
The proposal is good but I'd change it to do all the modification in /etc/pam.d/system-auth with calling pam_succeed_if and skipping pam_systemd if the service is su or runuser (without -l).
I am sorry, but I am firmly of the opinion that we should bind the XDG_RUNTIME_DIR stuff, the bus, the user session and the audit session together, and that "su" should only do the minimal work beyond that. Closing.
(In reply to comment #38) > I am sorry, but I am firmly of the opinion that we should bind the > XDG_RUNTIME_DIR stuff, the bus, the user session and the audit session > together, and that "su" should only do the minimal work beyond that. You are absolutely right about "su". However I disagree with "su -". "su -" should bring you brand new session. Please note that in this usecase auditing point of view and user point of view are different. From auditing point of view you want to track which physical person does something and it's clear that if someone calls "su -", it's still physical person (i.e. same user who logged through ssh/gdm/kdm etc). I.e. you need auditing for tracking which physical person is logged in. However from user point of view, I expect that computer thinks that I'm brand new user when I call "su -", even when I'm same physical person. So "su -" (however not "su") should create brand new session, with new bus, new XDG_ dirs etc. Don't you think that goals of auditing and goals of user sessions are pretty different? Reopening for further consideration.
I completely agree with Adam here. The loginuid purpose is auditing and should not be bound with the user point of view.
As the original poster I would like to second comment #39 The ability to have a fully functional "su - user2" session is a fundamental user requirement particularly for testing or development activities.
Well, there is never geing to be a "fully functional" implementation of "su -" because it always inherits state from the session, and that state is quite substantial. I mean, you can reopen this bug as much as you want, but I fundamentally believe that the scheme of "su" (or "su -" if you want to nitpick), can never work for desktop applications. You can lie to yourself, and claim D-Bus wouldn't exist and what else, but I don't see why systemd should play this game of pretending. I am not binding our session definition to the audit sessionid because it was the same thing, but because it turned out to have the same lifecycle, and we thus just decided that we can avoid a new identification scheme, and just reuse the id audit introduced. Anyway, closing again. This can never fly. And the same way as the destination user might or might not get access to the bus, it should also get or not get access to the XDG_RUNTIME_DIR. It's the same thing. And to PA, and whatnot. I am not going to handle XDG_RUNTIME_DIR differently from the rest.
Is this such an unreasonable thing to want to do ? In one terminal ja@ferrari ~ 2$ su - Password: [root@ferrari:~]$ gedit test1 (XDG_RUNTIME_DIR set to UID of ja) In 2nd terminal ja@ferrari ~ 1$ gedit test2 ** (gedit:3096): CRITICAL **: unable to create file '/run/user/1050/dconf/user': Permission denied. dconf will not work properly. ** (gedit:3096): CRITICAL **: unable to create file '/run/user/1050/dconf/user': Permission denied. dconf will not work properly. Reversing the order of editing only delays the occurrence of the problem
(In reply to comment #42) > Well, there is never geing to be a "fully functional" implementation of "su > -" because it always inherits state from the session, and that state is > quite substantial. Care to explain what exactly is inherited through loginuid? > I mean, you can reopen this bug as much as you want, but I fundamentally > believe that the scheme of "su" (or "su -" if you want to nitpick), can > never work for desktop applications. It worked for years well enough, only having to set up xauth to let two separate environments access the same display. What made it suddenly impossible? You've mentioned audio - couldn't it be solved by a similar authentication forwarding mechanism? > You can lie to yourself, and claim > D-Bus wouldn't exist and what else, but I don't see why systemd should play > this game of pretending. AFAIK D-Bus uses DBUS_SESSION_BUS_ADDRESS, which can be separate; org.freedesktop.DBus.GetConnectionUnixUser does not use the loginuid. What exactly is problematic about D-Bus? > Anyway, closing again. This can never fly. And the same way as the > destination user might or might not get access to the bus, it should also > get or not get access to the XDG_RUNTIME_DIR. It's the same thing. When an unprivileged-user-foo does (su - unprivileged-user-bar), the user "foo" should not be asked to give away access to all of XDG_RUNTIME_DIR. That would make (su -) a "please compromise me" command.
*** Bug 965419 has been marked as a duplicate of this bug. ***
Re [comment 29]: > If you want a fully detached text session then use "ssh localhost" or so, > which virtualizes everything. True, I wonder when it becomes impossible to send GUI notifications through SSH (using standard programs and default settings): [bug 915346].
*** Bug 999707 has been marked as a duplicate of this bug. ***
This is breaking tightvnc-server (F19), that starts the sessions via systemd with ExecStart=/sbin/runuser -l <USER> -c "/usr/bin/vncserver ..." Comment 34 explains very well why this is a bug, and Comment 35 offers a reasonable path to find a fix. May be it is time to introduce a "--subsession" flag to "su", that works like "--login" plus the PAM/systemd calls needed to spawn the sub-session. Lennart, you are blocking this bug because it hurts your design paradigm. The use cases exposed here were not taken into account when the design was done, it is time to integrate them. Your postulate "This can never fly" is a poor excuse, Linux gives us wings. Multi-user desktops have been working for ages, now they are broken. Please help us find a reasonable trade-off!
It's definitely a bug that su - username doesn't work correctly. This breaks libguestfs which wants to put a socket into $XDG_RUNTIME_DIR but cannot if the user has su - into the account. I guess our only workaround is to stop using XDG_RUNTIME_DIR and to dissuade anyone else from using too.
The XDG Base Directory Specification says that the "directory MUST be owned by the user, and he MUST be the only one having read and write access to it", so the "su -" behavior is non-compliant. su isn't just passing through an existing environment variable, it's systemd's PAM module that causes this, so the fix really has to be in systemd.
From the perspective of "pkexec", we go out of our way to explicitly clear all envronment variables (e.g. DISPLAY) except for a special whitelist. But pam_systemd.so then *injects back* a broken XDG_RUNTIME_DIR. That just has to be wrong. Right, Lennart? There are a few options here. One that occurs to me is for pam_systemd.so to special case XDG_RUNTIME_DIR when uid != loginuid. We could leave XDG_RUNTIME_DIR unset, and apps would have to fall back. But as with most other people in this thread, I'm really concluding that pam_systemd.so should explicitly use getuid() for XDG_RUNTIME_DIR.
Im setting this to priority medium and severity medium, as this is annoying to the enduser and the disussion seems to lead nowhere. we learned for years, that "su -" was the way to go for starting programs as another user. now (YEARS ago) someone (maybe even a group) changes that behaviour and breaks alot of other programs and the outcome is some academic parlay. asked frankly: *) will there be a solution? *) from whom? *) when? if there will be no solution, we could take actions against that (by modifying software not to use XDG_RUNTIME_DIR, which would be wrong in my opinion, but if this is the only solution: go for it. all we need is a decision.
Hi everyone, In Ubuntu, raring used libpam-xdg-support which was setting XDG_RUNTIME_DIR or not based on getuid(). In Saucy, it's changed to the systemd PAM module and the behaviour is different. Say joe is user 1000, in raring his runtime directory was: - /run/user/joe (when running an app) - /home/joe/.cache (when running an app with sudo) - /root/.cache (when running an app with gksu) - /run/user/root (when running an app as root after an "su -") In saucy, his runtime directory is: - /run/user/1000 (when running an app) - /home/joe/.cache (when running an app with sudo) - /root/.cache (when running an app with gksu) - /run/user/1000 (when running an app as root after an "su -") As you can see it's the exact same (other than the fact that we've traded usernames for uids as required upstream) for every case except for "su -". sudo seems to fall in a category where it's using the fallback... I wish it didn't write root files in the ~ dir, but at least that worked. Before I go on further, let me say that I've no experience with systemd (this is all new to me), very little with PAM and I'm not here to have an opinion but to seek your advice. It looks to me like systemd behaves the way it should but that breaks with the way things worked before. Is the solution either for systemd to set XDG_RUNTIME_DIR differently when the UID is 0, or for techs like glib and apps using this variable, to only rely on it when the UID isn't 0? How should this be tackled by distributions between an upstream solution is adopted? - Should we patch glib and individual apps to use a different runtime directory than XDG_RUNTIME_DIR when UID == 0? - Should we patch the systemd PAM module to set XDG_RUNTIME_DIR with a different value based on the uid and not the loginuid? We found a really hacky solution. Adding the following to /etc/profile sets XDG_RUNTIME_DIR the way the Ubuntu pam module used to set it in raring: if [ "`id -u`" -eq 0 ]; then mkdir -p /run/user/0 XDG_RUNTIME_DIR='/run/user/0' fi I hope I won't get laughed at for mentioning that hack :) I'm sure you guys will work out a proper solution. In the meantime we need a fix or a workaround. This affects almost all distros out there, with apps crashing all over the place, desktops freezing, dconf, pulseaudio breaking etc.. Is the /etc/profile hack a bad workaround? Would it tackle all cases? Would there be issues in your opinion? Is it the worst idea you've read in a long time? or does it sound like a good temporary solution? Thanks in advance for your expertise on this and good luck from us in agreeing on a solution.
(In reply to Clement Lefebvre from comment #53) > Is the solution either for systemd to set > XDG_RUNTIME_DIR differently when the UID is 0, or for techs like glib and > apps using this variable, to only rely on it when the UID isn't 0? [...] > - Should we patch glib and individual apps to use a different runtime > directory than XDG_RUNTIME_DIR when UID == 0? The problem is the exact opposite of this. When someone is root and 'su -' to a user, XDG_RUNTIME_DIR still points to the root-owned directory and so is unusable by applications. I am recommending that no one uses XDG_RUNTIME_DIR at all since you cannot be sure it exists and has usable permissions.
su is the problem, not XDG_RUNTIME_DIR. There is simply no way to make su behave 'correctly' wrt to all the things a modern application might need from the user session. su is at best sufficient for running simple commandline tools like ls
Here's a scenario where this freezes the desktop entirely: - Open a Cinnamon session - Open nemo - Right-click a directory and select "Open as Administrator" - Wait a few minutes The entire desktop freezes. You can tail -f your .xsession-errors to see that the two nemo (the one run by cinnamon-session as you, and the one run as root via pkexec) collide with the same runtime directory (/run/user/1000). The root nemo is using dconf which creates a root:root rw------- dfonf/user file in /run/user/1000. While that file exists, any application using dconf can either crash or freeze, as dconf is unable to function correctly. What usually happens in Cinnamon is that cinnamon-settings-daemon is the first to freeze. In this example I used nemo and cinnamon, but this would happen with any other components using dconf, or even glib, or XDG_RUNTIME_DIR directly (like pulseaudio). What we're doing at the moment is switching nemo to use gksu instead of pkexec... and we're considering patching glib to stop using XDG_RUNTIME_DIR entirely. Of course glib is doing what it should, and so is pkexec.. and according to upstream so is systemd, but as you can see there's absolutely no way we can ship with a bug that critical. Apps cannot use the same runtime path when they are elevated with admin permissions, because they create files which permissions prevent other apps to access thus generating crashes and freezes. This problem is brand new in Ubuntu. I understand that from a design point of view there might be issues with su and all, but we did not face random loss of pa servers, DE freezes and app crashes like we're facing now. Again, I've no opinion as to which components should adapt here, but there is a clear issue and a huge impact on the users.
(In reply to Richard W.M. Jones from comment #54) > The problem is the exact opposite of this. When someone is root > and 'su -' to a user, XDG_RUNTIME_DIR still points to the root-owned > directory and so is unusable by applications. It works both ways -- in both cases the program you run under su gets an $XDG_RUNTIME_DIR which isn't owned by the target user, which either (1) results in EPERM issues (for "su user" from root) or (2) hijacking files and changing their owner (for "su -" from user). > I am recommending that no one uses XDG_RUNTIME_DIR at all since you > cannot be sure it exists and has usable permissions. The idea is fine in general, it's just that due to this pam_systemd bug it doesn't promise what it says in the specification ("directory MUST be owned by the user"). Taking Lennart's concerns into account, I think an acceptable compromise would be for pam_systemd to unset $XDG_RUNTIME_DIR if it already exists but isn't owned by geteuid(). Then the program you run under su won't use a wrong runtime dir any more, but also doesn't pretend to be a full session. (In reply to Matthias Clasen from comment #55) > su is the problem, not XDG_RUNTIME_DIR. It's not -- su has nothing to do with $XDG_* stuff. It's just running the standard PAM modules. For the record, David proposed a workaround for pulse in http://lists.freedesktop.org/archives/pulseaudio-discuss/2013-November/019121.html, but that would need to be applied to dconf, dbus, and everything else that uses $XDG_RUNTIME_DIR. That's just wrong, this check should be done in the pam_systemd dir.
(In reply to Martin Pitt from comment #57) > Taking Lennart's concerns into account, I think an acceptable compromise > would be for pam_systemd to unset $XDG_RUNTIME_DIR if it already exists but > isn't owned by geteuid(). Then the program you run under su won't use a > wrong runtime dir any more, but also doesn't pretend to be a full session. I still hope that we'll eventually see something like XDG_RUNTIME_DIR that is universally available, so that we can avoid sprinkling fallback code across tons of programs (and that fallback code tends to be buggy).
Created attachment 823388 [details] pam: Check $XDG_RUNTIME_DIR owner This patch only sets $XDG_RUNTIME_DIR if its owned by the user. This fulfills the basedir spec in a minimal way. I can't say I'm truly happy with this (this is a new user session and should get its own runtime dir), but as this is contentious I'm not shooting for that. With that minimal solution we at least stop the dconf/pulse bugs. This is a patch against current upstream trunk. I applied a backport to 204 to the Ubuntu package (it needs some fuzzing due to the slightly changed code structure).
Can you send this patch to systemd-devel? Red Hat Bugzilla is a crappy patch system. On the actual content of your patch: * We could also check whether uid != getuid() - i mean we know the code above uses loginuid, so indirecting via lstat() is weird. But I'm OK with the code as is. * No need to log a message when this happens. We know it will happen, it's "normal", and there are already several log messages emitted for su.
Hi Martin, In your patch you're checking for the ownership of the runtime dir. That's a good idea but I don't think it's enough. For instance we're observing a conflict on /run/user/1000/dconf/user when we run dconf apps as root. The conflict isn't because of the permissions of the runtime dir (in our tests, they seem to always be right.. i.e. /run/user/1000 belongs to 1000:1000, and so does the dconf dif). The problem is with the "user" file created by dconf in /run/user/1000/dconf/. When it exists (it doesn't always since it's removed when dconf no longer needs it), it either belongs to 1000, or to root. Of course in a systemd patch, you can't check that specific dconf file. But it's just to illustrate that although the issue is with file permissions, I don't think a fix should involve checking these permissions, or at least that's not sufficient. I think Colin is right here, we need to check the user id and categorically forbid different users (root included) to share the same runtime path. In raring, the first thing libpam-xdg-support did was to check for the user ID.
(In reply to Colin Walters from comment #60) > Can you send this patch to systemd-devel? Red Hat Bugzilla is a crappy > patch system. Can do, yes. > On the actual content of your patch: > > * We could also check whether uid != getuid() - i mean we know the code > above uses loginuid, so indirecting via lstat() is weird. But I'm OK with > the code as is. Does getuid() make any sense here? It's a PAM module, so do we ever expect this to be something else than root? > * No need to log a message when this happens. We know it will happen, it's > "normal", and there are already several log messages emitted for su. Ack. That was primarily for debugging, so I guess I'll tone it down to LOG_DEBUG.
(In reply to Clement Lefebvre from comment #61) > In your patch you're checking for the ownership of the runtime dir. That's a > good idea but I don't think it's enough. > > For instance we're observing a conflict on /run/user/1000/dconf/user when we > run dconf apps as root. But these shouldn't use that runtime dir in the first place. As soon as you have a root process scribbling over your user's runtime dir, you have lost. That's precisely what we want to avoid here, isn't it? > The problem is with the "user" file created by dconf in > /run/user/1000/dconf/. When it exists (it doesn't always since it's removed > when dconf no longer needs it), it either belongs to 1000, or to root. It should never belong to root. > I think Colin is right here, we need to check the user id and categorically > forbid different users (root included) to share the same runtime path. That's what this patch is supposed to do. What would be the scenario where that fails? Note that there are still cases where this would fail. For example, if you use sudo (without -i), that doesn't involve PAM, but might (depending on the config) keep the $XDG_* variables around for the process you run through it. That doesn't happen on the default sudo configuration, but you can tell it to keep the whole environment.
Clement: basically Martin's patch should prevent that situation from occurring in the first place. (It won't undo the damage, but...no one is talking about a plan for that since it's *really* ugly)
(In reply to Colin Walters from comment #64) > (It won't undo the damage, but...no one is talking about a plan for that > since it's *really* ugly) No, but /run being a tmpfs, the next reboot or at least session restart will clean it up. Before you do that, you won't run the new PAM module anyway.
(In reply to Martin Pitt from comment #65) > No, but /run being a tmpfs, the next reboot or at least session restart will > clean it up. Before you do that, you won't run the new PAM module anyway. Right, for some reason I had been thinking files were written owned by root to /home/user, but that's not the case. (In reply to Martin Pitt from comment #62) > > Does getuid() make any sense here? It's a PAM module, so do we ever expect > this to be something else than root? Yeah, I meant: pam_get_item(pamh, PAM_USER, &user); But I'm unable to construct a scenario where this really matters, so let's just go with your lstat() approach.
(In reply to Colin Walters from comment #60) > Can you send this patch to systemd-devel? Red Hat Bugzilla is a crappy > patch system. Done now, with INFO -> DEBUG as discussed. > On the actual content of your patch: Thanks for your review!
Hi Martin, Colin, "That's what this patch is supposed to do. What would be the scenario where that fails?" --> Sorry about this, you're right. I reviewed the patch again and it should prevent root from using the same runtime dir. I mustn't have read it properly the first time and I thought you were testing access rather than ownership. It looks good and it should take care of the test-case I mentioned pretty well.
(In reply to Colin Walters from comment #60) > Can you send this patch to systemd-devel? Red Hat Bugzilla is a crappy > * We could also check whether uid != getuid() - i mean we know the code > above uses loginuid, so indirecting via lstat() is weird. But I'm OK with > the code as is. Sorry for the confusion (on both sides, I suppose). For me audit_loginuid_from_pid() does not actually succeed, so it's falling back to pam_get_username(). But *if* that succeeds, the current patch is wrong indeed, we need to *always* get the username from PAM. But that's indeed a separate issue (and in fact it seems it's the original issue of this bug, which I didn't really fully understand until now). So we need to check pam_get_user() against the owner of $RUNTIME_DIR (as logind always gives us the one from the session, not the one for the target user) to fix the "root destroys my runtime dir" issue, and secondly we would ideally drop the audit_loginuid_from_pid() thing as it's not really what we want. I'll follow up on the upstream ML with updated patches.
*** Bug 1037285 has been marked as a duplicate of this bug. ***
For those not following the list, http://cgit.freedesktop.org/systemd/systemd/commit/?id=baae0358f349870544884e405e82e4be7d8add9f I haven't tried testing this commit myself, as http://cgit.freedesktop.org/polkit/commit/?id=8635ffc16aeff6a07d675f861fe0dea03ea81d7e works around it now too.
Could you please apply those commits in fedora. That /run/user/1000/dconf/ isn't writeable produce crashes in other applications. https://bugzilla.redhat.com/show_bug.cgi?id=1044542 Thank you
*** Bug 1044542 has been marked as a duplicate of this bug. ***
*** Bug 961890 has been marked as a duplicate of this bug. ***
I applied the work-around given by Wolfgang in https://bugzilla.redhat.com/show_bug.cgi?id=961890#c39 to get around the problem. I am user 'gavin' (1000). # cd /run/user/1000/dconf # ll total 4 -rw-------. 1 root root 2 Jan 18 08:27 user # chown -R gavin:gavin user # ll total 4 -rw-------. 1 gavin gavin 2 Jan 18 15:05 user # I was then able to start caja without having to logout or reboot. Thanks Wolfgang!
Like to hear that something going to be fixed here. Will this fix be available in Fedora 20 or not?
*** Bug 1059388 has been marked as a duplicate of this bug. ***
*** Bug 1000164 has been marked as a duplicate of this bug. ***
Another user waiting for the patch to manifest itself to F20. Kernel-3.13.3-201.x86_64 Mate desktop
The fix should be available in Fedora20 now: (7:58:39 AM) ccrouch: is there any chance of getting http://cgit.freedesktop.org/systemd/systemd/commit/?id=baae0358f349870544884e405e82e4be7d8add9f backported to systemd v2.0.8 in Fedora20? (7:58:39 AM) ccrouch: it would address https://bugzilla.redhat.com/show_bug.cgi?id=753882#c49 which I and others are running into (8:03:33 AM) zdzichu: ccrouch: it's already in v208 (no dots) in F20 branch (8:03:49 AM) zdzichu: http://pkgs.fedoraproject.org/cgit/systemd.git/commit/0268-pam_systemd-do-not-set-XDG_RUNTIME_DIR-if-the-sessio.patch?h=f20&id=a52f6741bd20d8383d75ad852a37699fbfb4b896 (8:05:59 AM) zdzichu: ccrouch: in 208-15 http://pkgs.fedoraproject.org/cgit/systemd.git/commit/systemd.spec?h=f20&id=a52f6741bd20d8383d75ad852a37699fbfb4b896
looks like we're working again? ===== [flowerpt@aughra ~]$ rpm -q systemd systemd-208-16.fc20.x86_64 [flowerpt@aughra ~]$ echo $XDG_RUNTIME_DIR /run/user/1001 [flowerpt@aughra ~]$ ls -ld /run/user/1001 drwx------ 9 flowerpt flowerpt 220 Apr 24 00:32 /run/user/1001 [flowerpt@aughra ~]$ su - Password: Last login: Fri Apr 25 10:12:08 EDT 2014 on pts/4 [root@aughra ~]# echo $XDG_RUNTIME_DIR [root@aughra ~]# ls -ld /run/user/1001 drwx------ 9 flowerpt flowerpt 220 Apr 24 00:32 /run/user/1001 [root@aughra ~]# su - flowerpt Last login: Fri Apr 25 10:12:18 EDT 2014 on pts/4 [flowerpt@aughra ~]$ echo $XDG_RUNTIME_DIR /run/user/1001 [flowerpt@aughra ~]$ ls -ld /run/user/1001 drwx------ 9 flowerpt flowerpt 220 Apr 24 00:32 /run/user/1001 =====
Hello Any chance this update could be made available for Fedora 19? Much appreciated and kind regards.
*** Bug 1104951 has been marked as a duplicate of this bug. ***
*** Bug 1165182 has been marked as a duplicate of this bug. ***
msg = 0xc5ab90 "unable to create file '/run/user/1000/dconf/user': Keine Berechtigung. dconf will not work properly." msg_alloc = 0xc5ab90 "unable to create file '/run/user/1000/dconf/user': Keine Berechtigung. dconf will not work properly. He guys, the issue is back in f21.
*** Bug 984279 has been marked as a duplicate of this bug. ***
Is there an upstream bug report ? If not, I suggest this could be a better place to discuss this issue. Or perhaps not. I think, as many others in this thread, that the solution we came to is a half solution only. Not setting XDG_RUNTIME_DIR at all when using 'su -l' breaks many things, and not just graphical applications. I'm one of those people that things running graphical applications using su is a bad idea. There is a reason behind the distinction between 'su' and 'su --login'. The latter is supposed to recreate a complete login environment. I think it then should also register a session within logind and of course provide a XDG_RUNTIME_DIR. I came across this issue trying to use 'systemctl --user' over 'su' to activate a (pulseaudio) systemd unit for a ad-hoc user. This command appears in a deployment shell script and I had to set XDG_RUNTIME_DIR manually in a non portable way. I do not like it. This is to say that the problem is not just with graphical application, but to anything that happens to use XDG_RUNTIME_DIR. And it seems that more and more console applications should use this. Perhaps using 'su' for that is wrong and we should have another command that runs the exact same pam modules than login.
(In reply to Mildred from comment #87) … > I think, as many others in this thread, that the solution we came to is a > half solution only. Not setting XDG_RUNTIME_DIR at all when using 'su -l' > breaks many things, and not just graphical applications. I'm one of those > people that things running graphical applications using su is a bad idea. +1 … > This is to say that the problem is not just with graphical application, but > to anything that happens to use XDG_RUNTIME_DIR. And it seems that more and > more console applications should use this. All graphical applications that need root access use gksu / pkexec, so this will call su (without -l option). > Perhaps using 'su' for that is wrong and we should have another command that > runs the exact same pam modules than login. So do you think a wrapper für 'su' will solve most of the issues? Please don't be so naive to think more complexity will solve anything, there's already too much of it! [rant] Reducing complexity should always be a big goal. [/rant]
> So do you think a wrapper für 'su' will solve most of the issues? Please don't be so naive to think more complexity will solve anything, there's already too much of it! [rant] Reducing complexity should always be a big goal. [/rant] I was more thinking of another PAM configuration with a slightly different semantic than su. it could be another command like `su` or an option that would use a different PAM configuration. It would be identical to the login command. Then again, that's probably what `su --login` is for.
The new scratch build is okay with a nice menu icon. But the icon is not the same as the window icon. Tested with the x86_64 package.
(In reply to Raphael Groner from comment #90) This was spam, sorry for the noise. :(((
*** Bug 1234318 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Since the discussion in this bugzilla really died out a year ago, and there's no clear resolution, any further discussion about propagating/unsetting XDG_RUNTIME_DIR should be moved upstream.
Setting the resolution, per comment 94.
It is impossible to use DE MATE. All the same error described above (using 100% CPU and memory leak.) strace -f $(pidof mate-settings-daemon | sed 's/([0-9]*)/-p \1/g'): 6240 recvmsg(3, 0x7ffda79f9640, 0) = -1 EAGAIN (Resource temporarily unavailable) 6240 recvmsg(3, 0x7ffda79f9640, 0) = -1 EAGAIN (Resource temporarily unavailable) 6240 munmap(0x7f87d53b6000, 21236) = 0 6240 access("/run", F_OK) = 0 6240 stat("/run", {st_mode=S_IFDIR|0755, st_size=860, ...}) = 0 6240 access("/run/user", F_OK) = 0 6240 stat("/run/user", {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0 6240 access("/run/user/1000", F_OK) = 0 6240 stat("/run/user/1000", {st_mode=S_IFDIR|0700, st_size=140, ...}) = 0 6240 access("/run/user/1000/dconf", F_OK) = 0 6240 stat("/run/user/1000/dconf", {st_mode=S_IFDIR|0700, st_size=60, ...}) = 0 __________________________________________________________________________ 6240 open("/run/user/1000/dconf/user", O_RDWR|O_CREAT, 0600) = -1 EACCES (Permission denied) __________________________________________________________________________ 6240 write(2, "\n(mate-settings-daemon:6240): dc"..., 150) = 150 6240 close(-1) = -1 EBADF (Bad file descriptor) 6240 open("/home/coolaller/.config/dconf/user", O_RDONLY) = 16 6240 fstat(16, {st_mode=S_IFREG|0644, st_size=21236, ...}) = 0 6240 mmap(NULL, 21236, PROT_READ, MAP_PRIVATE, 16, 0) = 0x7f87d53b6000 6240 close(16) = 0 6240 poll([{fd=3, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=3, revents=POLLOUT}]) 6240 writev(3, [{"\203\2\1\0", 4}, {NULL, 0}, {"", 0}], 3) = 4 6240 poll([{fd=3, events=POLLIN}], 1, 4294967295) = 1 ([{fd=3, revents=POLLIN}]) 6240 recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"\1\2\353+\200\0\0\0\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 544 This continues from 2013, is it really impossible to fix? Do something with this error, please!
*** Bug 1292670 has been marked as a duplicate of this bug. ***
Another report about!!! https://bugzilla.redhat.com/show_bug.cgi?id=1292670 Please fix it. https://github.com/linuxmint/systemd-rosa/commit/50d0f45f22494e004b927060bc0fc2d32136dee6 LinuxMint can do that. Why not fedora ? Maybe you want that users switch to LinuxMint.
Wolfgang, it seems to be fixed in RHEL.
*** Bug 1357129 has been marked as a duplicate of this bug. ***
*** Bug 1403257 has been marked as a duplicate of this bug. ***
(In reply to Jan Synacek from comment #94) > Since the discussion in this bugzilla really died out a year ago, and > there's no clear resolution, any further discussion about > propagating/unsetting XDG_RUNTIME_DIR should be moved upstream. Since I've just hit by this, in 2017, with Fedora 25, any idea what ever happened to the upstream discussion?
Hitting this still in 2020 under RHEL 7.8.
For those poor souls that get here and see that it will never be fixed: Workaround: Add a line to the startup script of users that you might like to su to, which removes the offending environment variable XDG_RUNTIME_DIR bash users: unset XDG_RUNTIME_DIR csh users: unsetenv XDG_RUNTIME_DIR
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days