Bug#905409: upgrade of util-linux and login break the xhost command for other users
Hello Andreas Henriksson, On Sun, Aug 12, 2018 at 05:35:35PM +0200, Andreas Henriksson wrote: > Hello Helge Kreutzmann, > > Sorry if my comments sounded too negative, some more reasoning below. No problem. > On Sun, Aug 12, 2018 at 04:35:47PM +0200, Helge Kreutzmann wrote: > > Hello Andreas Henriksson, > > I'm a bit puzzled by your e-mail. Simon asked me to provide some text, > > Chris prodded me and Davide and Simon reviewed my text (which does not > > imply that it is perfect or so). > [...] > > Well, I think for _Debian_ users the change *is* suprising, but only > > because the su version (and its configuration / behaviour) has > > changed. > [...] > > If the change in behaviour isn't something we can just live with > I think solving it via pam configuration seems like the best course > of action. Please see the mail I just quickly banged together and > sent to debian-devel (with you BCCed). Yes, I read it. Thanks for letting me know. > [...] > > Which is clearly not the case here. So upstreaming is no option. > > Carrying patches downstream forever isn't something I'm very Not forever: Only until the next stable release has happend. Then drop it again. Clear timeline. > enthusiastic about as you probably understand. As you might have > also noticed I've removed myself from util-linux maintenance (lack of No, I've not researched about util-linux any further, I just stumbled over the bug and wanted to add my few cents to help resolving it. I belive writing patches is better than simply complaining, and for documentation this is within my skill set. > time). I thus don't really see it suitable for me to add patches like > this that someone else gets to maintain, but anyone with upload > privilegies can upload a NMU themselves ofcourse! (so there's no need > to wait for me to do it.) Hopfeully your successor can chime in and put his/her POV on this. > OTOH please consider I've spent years to back util-linux out of the > corner it was stuck in. Non upstreamed/upstreamable patches was part > of the problem. I would very much appreciate some sympathy on that > rather than pushing things back into the corner as soon as I turn my > back. ;P Thanks for your efforts. And I perfectly understand that you want to avoid (ongoing) distribution specific patches where possible. > [...] > > Thanks. But as stated earlier, having it in NEWS is only part of the > > solution, [...] > > I'd even call it a workaround which simply serves the purpose of me > not having to touch the pam configuration with zero peer review. > (And I also doubt more people read manpages than read NEWS. Targeting > release notes might be a much better option. Things that aren't new > but just best practises we want to spread the knowledge of might be > better suited for debian-handbook or similar) And again who reads the release notes, especially ordinary users who (like me at work) simply get a system delivered, without any further "changelog", "NEWS", "release information"? There is no perfect solution. So besides the NEWs file you mentioned, the other two options could work in parallel. [...] > Sorry for sending another sloppy mail today, but hopefully you can > make some sense of what I wrote. Really need to attend personal > things now instead Final words, don't expect me to actually maintain > util-linux anymore. Don't wait for me to upload what you think is > sensible. I wish you good success to your personal endavours and thanks for the time you invested in Debian. I'm not going to do an NMU for a documentation patch, so let's wait for your sucessor. (For me the bug is solved, this bug report is just about spreading the word appropriately). Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: Digital signature
Bug#905409: upgrade of util-linux and login break the xhost command for other users
Hello Helge Kreutzmann, Sorry if my comments sounded too negative, some more reasoning below. On Sun, Aug 12, 2018 at 04:35:47PM +0200, Helge Kreutzmann wrote: > Hello Andreas Henriksson, > I'm a bit puzzled by your e-mail. Simon asked me to provide some text, > Chris prodded me and Davide and Simon reviewed my text (which does not > imply that it is perfect or so). [...] > Well, I think for _Debian_ users the change *is* suprising, but only > because the su version (and its configuration / behaviour) has > changed. [...] If the change in behaviour isn't something we can just live with I think solving it via pam configuration seems like the best course of action. Please see the mail I just quickly banged together and sent to debian-devel (with you BCCed). [...] > Which is clearly not the case here. So upstreaming is no option. Carrying patches downstream forever isn't something I'm very enthusiastic about as you probably understand. As you might have also noticed I've removed myself from util-linux maintenance (lack of time). I thus don't really see it suitable for me to add patches like this that someone else gets to maintain, but anyone with upload privilegies can upload a NMU themselves ofcourse! (so there's no need to wait for me to do it.) OTOH please consider I've spent years to back util-linux out of the corner it was stuck in. Non upstreamed/upstreamable patches was part of the problem. I would very much appreciate some sympathy on that rather than pushing things back into the corner as soon as I turn my back. ;P [...] > Thanks. But as stated earlier, having it in NEWS is only part of the > solution, [...] I'd even call it a workaround which simply serves the purpose of me not having to touch the pam configuration with zero peer review. (And I also doubt more people read manpages than read NEWS. Targeting release notes might be a much better option. Things that aren't new but just best practises we want to spread the knowledge of might be better suited for debian-handbook or similar) It seems to me that the pam configuration, even ignoring the current implementation differences, is long overdue for an overhaul (based on the bug reports zeha reassigned). Hopefully we can get a discussion going on what a suitable pam configuration should look like and get enough people involved to make a good tradeoff and get all changes peer reviewed. I however fear that everyone who has prior PAM knowledge knows how easy it is to get things wrong and are smart enough to keep their hands away. Possibly we might need to find new people who haven't already cut themselves on pam configuration to become interested and involved, and learn as they go (to eventually also learn to never touch pam configuration ever again). Sorry for sending another sloppy mail today, but hopefully you can make some sense of what I wrote. Really need to attend personal things now instead Final words, don't expect me to actually maintain util-linux anymore. Don't wait for me to upload what you think is sensible. Regards, Andreas Henriksson
Bug#905409: upgrade of util-linux and login break the xhost command for other users
Hello Andreas Henriksson, I'm a bit puzzled by your e-mail. Simon asked me to provide some text, Chris prodded me and Davide and Simon reviewed my text (which does not imply that it is perfect or so). On Sun, Aug 12, 2018 at 05:56:14AM +0200, Andreas Henriksson wrote: > Hello Helge Kreutzmann, > > I'm skeptical how relevant it is to document how X and ssh works > in the _su_ manpage, but either way since you're patching the I'm fine to skip the X and ssh part, but as stated above the reviewer liked the idea and I actually tried to keep it short and simple. And no, I don't intend to go into any more details, which would be way over top in the su manpage. > manpage this is something you want to send upstream for review if > you think it's worth persuing and my opinion doesn't count there. Well, I think for _Debian_ users the change *is* suprising, but only because the su version (and its configuration / behaviour) has changed. For upstream util-linux this is not the case, there no change has occured, only one more distribution is now using the su implementation. So I could very well understand if util-linux upstream would reject the change, as there nothing has happend (and why should users of other distributions care about a Debian specific issue?). > As always to increase chances of a favourable review getting the > administrative details right from the start is useful, so please > see Documentation/howto-contribute.txt As you can see from the bug log, there already was some review. Looking at howto-contribute.txt, it also says: * neutrality: the files in util-linux should be distribution-neutral. Which is clearly not the case here. So upstreaming is no option. > (You might also want to replace references to 'Debian 9' with > 'shadow su implementation' or similar.) I think the explicit reference to Debian serves a purpose here: The user might not know that previous versions of su came from shadow, and current ones from util-linux. They just see their workflow break. > I'll add a note to util-linux.NEWS about DISPLAY and XAUTHORITY. Thanks. But as stated earlier, having it in NEWS is only part of the solution, because in larger installations NEWS are not seen by ordinary users, e.g at work I've never seen any NEWS file, I simply was informed than an upgrade had happened, so I rely on other information sources, where man pages are my first try. (And search in the web and hopefully finding bug reports like this are really disliked last options.) So I would ask you to carry a patch simliar to the one proposed (maybe stripped, if you don't like the part about better solutions, security wise) until the next Debian version is released and then drop it again, so people on the next stable version can read it in the man page. If you agree I'm fine to further tune the patch. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: Digital signature
Bug#905409: upgrade of util-linux and login break the xhost command for other users
Hello Helge Kreutzmann, I'm skeptical how relevant it is to document how X and ssh works in the _su_ manpage, but either way since you're patching the manpage this is something you want to send upstream for review if you think it's worth persuing and my opinion doesn't count there. As always to increase chances of a favourable review getting the administrative details right from the start is useful, so please see Documentation/howto-contribute.txt (You might also want to replace references to 'Debian 9' with 'shadow su implementation' or similar.) I'll add a note to util-linux.NEWS about DISPLAY and XAUTHORITY. Regards, Andreas Henriksson
Bug#905409: upgrade of util-linux and login break the xhost command for other users
Hello Davide, hello Simon, On Thu, Aug 09, 2018 at 09:53:48PM +0200, Davide Prina wrote: > On 09/08/2018 21:06, Helge Kreutzmann wrote: > > >+Use a separate X display (e.g. "Switch User" in GNOME, or the equivalent > >fast-user-switching feature in other desktop environments), > > here probably it is better to say that the user can switch from one to other > user with the Ctrl-Alt-Fx keys > > >+Use ssh, e.g. "ssh -X -oForwardX11Trusted=no otheruser@localhost". > > and here, I think it is better to write somethings like: > +Use ssh, e.g. "ssh -X -oForwardX11Trusted=no $OTHERUSER@$LOCALHOST". > +Where $OTHERUSER is the user you want to use to execute commands > +and $LOCALHOST is your localhost (it can be: localhost, 127.0.0.1, ...) I introduced otheruser above. I updated the text to explicitly include localuser as well. > and probably it is better to mention that you need sshd process active in > your system (you must install openssh-server). Remember that this is not an introduction of how to use all those other tools but rather points to them. I explicitly referenced now the man page of ssh. > I don't know if it is better to evidence that with this solution you can > have performance problems and not all can work correctly as you expected. I think the man page is not the right place to discuss those issues. It is intended as first pointer for future reading or simply using (i.e. the user might now already about those solutions, but simply needs a gentle reminder). > >+Allow \fBsu\fR explicit display access by issuing "xhost > >+si:localuser:otheruser" in > > and here, I think it is better to write somethings like: > +explicit display access by issuing "xhost +si:localuser:$OTHERUSER" > ... > > >+the originating X session and "DISPLAY=:0 command" under \fBsu\fR. As stated above, I updated the introduction of the roles localuser and otheruser. > and here > +the originating X session and "DISPLAY=:0 $COMMAND" under \fBsu\fR. I don't know if using $COMMAND provides more clarity than command. > +or export the DISPLAY variable as "export DISPLAY=:0" > +and then execute all the commands with GUI you like: "$COMMAND &" > +where $COMMAND is the GUI command you like to exec (eg: qcalculate &) This is longer and I would rather avoid writing this, because using graphical applications should remain the exception, and explaining this here might people lend to have such shell open permanently and running much more than desired. And again, people who need this either know how to export the DISPLAY permanenetly or they can now look up other documentation to find out how to do it. Keep it short and simple and let the other documentation do its work. > Probably it is better to put some link to documentation > man sshd > man ssh_config > man sshd_config No, this is going beoynd what is needed here. In ssh(1) you get all the pointers. > man xhost I reworded the text to include this link. On Fri, Aug 10, 2018 at 08:13:05AM +0100, Simon McVittie wrote: > On Thu, 09 Aug 2018 at 21:06:37 +0200, Helge Kreutzmann wrote: > > +Further by default > > +.B su > > +does not allow the commands to access the current X display. > > This is perhaps misleading: su isn't allowing or denying anything, it's > the X server that isn't allowing other users to access it. Perhaps just > state the facts and let the user sort out the implications: "Unlike the > su implementation in Debian 9 and older releases, this su implementation > does not copy the X display address (DISPLAY) and credentials (XAUTHORITY) > to the commands"? I update the text. > There are two situations with different behaviour and expectations: > escalating privileges from a non-root user to root, and changing/dropping > privileges from a user (whether root or not) to a different non-root user. > > When escalating from an non-root user to root, the old su in src:shadow > copied the DISPLAY and XAUTHORITY variables to the root process. This > told X clients which X display they could use (DISPLAY), and also the > file containing credentials to use when authenticating to that display > (XAUTHORITY). The file whose name is the value of XAUTHORITY is normally > only readable by the user who owns the X display, but root can read it > anyway, because root is privileged and can exercise CAP_DAC_OVERRIDE. In > this situation, it is also unnecessary to defend against root being > able to escalate privileges to the invoking user (for instance via X > misconfiguration or via bugs like CVE-2016-2779), because root can do > that anyway. > > (It hopefully goes without saying that running X applications as root > is not a good idea, both because X applications and the X display trust > each other and because GUI libraries are a huge attack surface.) > > When switching from a user (root or not) to a different non-root user, > copying DISPLAY had the same effect as when escalating to root, but > copying XAUTHORITY would leave the target user's process trying to read
Bug#905409: upgrade of util-linux and login break the xhost command for other users
On Thu, 09 Aug 2018 at 21:06:37 +0200, Helge Kreutzmann wrote: > +Further by default > +.B su > +does not allow the commands to access the current X display. This is perhaps misleading: su isn't allowing or denying anything, it's the X server that isn't allowing other users to access it. Perhaps just state the facts and let the user sort out the implications: "Unlike the su implementation in Debian 9 and older releases, this su implementation does not copy the X display address (DISPLAY) and credentials (XAUTHORITY) to the commands"? There are two situations with different behaviour and expectations: escalating privileges from a non-root user to root, and changing/dropping privileges from a user (whether root or not) to a different non-root user. When escalating from an non-root user to root, the old su in src:shadow copied the DISPLAY and XAUTHORITY variables to the root process. This told X clients which X display they could use (DISPLAY), and also the file containing credentials to use when authenticating to that display (XAUTHORITY). The file whose name is the value of XAUTHORITY is normally only readable by the user who owns the X display, but root can read it anyway, because root is privileged and can exercise CAP_DAC_OVERRIDE. In this situation, it is also unnecessary to defend against root being able to escalate privileges to the invoking user (for instance via X misconfiguration or via bugs like CVE-2016-2779), because root can do that anyway. (It hopefully goes without saying that running X applications as root is not a good idea, both because X applications and the X display trust each other and because GUI libraries are a huge attack surface.) When switching from a user (root or not) to a different non-root user, copying DISPLAY had the same effect as when escalating to root, but copying XAUTHORITY would leave the target user's process trying to read a file to which they do not normally have read access, so simply using su was not sufficient even with the old src:shadow su, and setting up access for the target user with xhost (or xauth) was additionally required. In this situation, it normally *is* a concern if the target user can escalate to the privileges of the invoking user, either via X misconfiguration or via something like CVE-2016-2779: that would give the target user abilities that they did not previously have, defeating the value of using separate users. > +Use ssh, e.g. "ssh -X -oForwardX11Trusted=no otheruser@localhost". I don't actually know how much protection against keyloggers, input injection, output capture etc. you get from ForwardX11Trusted=no; you'd have to ask an X11 expert. It's also known to break some X apps (and in particular it forbids use of the selection, i.e. copy/paste), which is why Debian's ssh has been patched (since 2004, #237021) to default to ForwardX11Trusted=yes when X-forwarding is used (the upstream default is that -X implies -oForwardX11Trusted=no, and -Y is equivalent to -X -oForwardX11Trusted=yes). > +Allow \fBsu\fR explicit display access by issuing "xhost > +si:localuser:otheruser" This is misleading: the display access granted by xhost is not limited to the process tree rooted at su, but is granted to any (related or unrelated) process whose uid is otheruser. Perhaps "Allow X display access for processes running as \fIotheruser\fR by issuing \fBxhost +si:localuser:\fIotheruser\fR"? smcv
Bug#905409: upgrade of util-linux and login break the xhost command for other users
On 09/08/2018 21:06, Helge Kreutzmann wrote: +Use a separate X display (e.g. "Switch User" in GNOME, or the equivalent fast-user-switching feature in other desktop environments), here probably it is better to say that the user can switch from one to other user with the Ctrl-Alt-Fx keys +Use ssh, e.g. "ssh -X -oForwardX11Trusted=no otheruser@localhost". and here, I think it is better to write somethings like: +Use ssh, e.g. "ssh -X -oForwardX11Trusted=no $OTHERUSER@$LOCALHOST". +Where $OTHERUSER is the user you want to use to execute commands +and $LOCALHOST is your localhost (it can be: localhost, 127.0.0.1, ...) and probably it is better to mention that you need sshd process active in your system (you must install openssh-server). I don't know if it is better to evidence that with this solution you can have performance problems and not all can work correctly as you expected. +Allow \fBsu\fR explicit display access by issuing "xhost +si:localuser:otheruser" in and here, I think it is better to write somethings like: +explicit display access by issuing "xhost +si:localuser:$OTHERUSER" ... +the originating X session and "DISPLAY=:0 command" under \fBsu\fR. and here +the originating X session and "DISPLAY=:0 $COMMAND" under \fBsu\fR. +or export the DISPLAY variable as "export DISPLAY=:0" +and then execute all the commands with GUI you like: "$COMMAND &" +where $COMMAND is the GUI command you like to exec (eg: qcalculate &) Probably it is better to put some link to documentation man sshd man ssh_config man sshd_config man xhost ... Ciao Davide -- Dizionari: http://linguistico.sourceforge.net/wiki Motivi per non comprare/usare ms-windows-vista: http://badvista.fsf.org/ Non autorizzo la memorizzazione del mio indirizzo su outlook
Bug#905409: upgrade of util-linux and login break the xhost command for other users
Hello Chris, On Wed, Aug 08, 2018 at 08:58:24PM +0200, Chris Hofstaedtler wrote: > * Helge Kreutzmann [180808 18:57]: > > On Tue, Aug 07, 2018 at 08:20:23PM +0100, Simon McVittie wrote: > > > Andreas already asked for a merge request, so it seems that proposing a > > > patch would indeed be welcome. > > > > I'll do, incorporating your excellent explaination. I'll do so until > > the end of the week (latest). > > Gentle reminder about this. Here you are: --- ./su.1.orig 2017-09-27 11:05:13.717361420 +0200 +++ ./su.1 2018-08-09 21:04:24.370998117 +0200 @@ -261,6 +261,27 @@ .RS .br session required pam_lastlog.so nowtmp +.PP +.RE +Further by default +.B su +does not allow the commands to access the current X display. To allow +graphical applications with the privileges of a different user +(called "otheruser" in this example) several +options exists. These are, in order of preference (security-wise): +.RS 10 +.TP +o +Use a separate X display (e.g. "Switch User" in GNOME, or the equivalent fast-user-switching feature in other desktop environments), or a "thicker" remoting layer like VNC, Spice or Xpra. +.TP +o +Use ssh, e.g. "ssh -X -oForwardX11Trusted=no otheruser@localhost". +.TP +o +Allow \fBsu\fR explicit display access by issuing "xhost +si:localuser:otheruser" in +the originating X session and "DISPLAY=:0 command" under \fBsu\fR. +This has serious security implications and hence should only be used in +trusted environments. .RE .SH "SEE ALSO" .BR setpriv (1), Feel free to update. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: Digital signature
Bug#905409: upgrade of util-linux and login break the xhost command for other users
* Helge Kreutzmann [180808 18:57]: > On Tue, Aug 07, 2018 at 08:20:23PM +0100, Simon McVittie wrote: > > Andreas already asked for a merge request, so it seems that proposing a > > patch would indeed be welcome. > > I'll do, incorporating your excellent explaination. I'll do so until > the end of the week (latest). Gentle reminder about this. Thanks, Chris
Bug#905409: upgrade of util-linux and login break the xhost command for other users
Hello Simon, On Tue, Aug 07, 2018 at 08:20:23PM +0100, Simon McVittie wrote: > On Mon, 06 Aug 2018 at 17:31:35 +0200, Helge Kreutzmann wrote: > > this change (requiring a DISPLAY=:0) is really suprising. I'v used su > > for ages and a simple xhost + (yes, I know that this has security > > implications) was sufficient. > > "xhost +" grants access to your display to *literally any user*, > including special-purpose system users like "nobody" and the users > that run network servers. Please avoid this pattern! If you need to > grant unlimited access to your display to another user, at least use > "xhost +si:localuser:$THEIR_USERNAME". (Or, again, consider using a > separate X display, or Xpra, or similar.) I'm aware, but thanks for the pointer anyhow. > > Plese document this in a public place, the best would be the man page > > as that is where users are looking for (a NEWS entry would only catch > > administrators once). > > > > I suggest putting it under NOTES. If you like, I can draft up a patch. > > Andreas already asked for a merge request, so it seems that proposing a > patch would indeed be welcome. I'll do, incorporating your excellent explaination. I'll do so until the end of the week (latest). Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: Digital signature
Bug#905409: upgrade of util-linux and login break the xhost command for other users
Control: retitle 905409 util-linux: "su -" no longer copies DISPLAY and XAUTHORITY to child, but this is not documented I'm retitling the bug since the new su implementation does break patterns involving xhost that used to work, but it is not the xhost step that is affected, making the title misleading. On Sun, 05 Aug 2018 at 05:40:32 +0200, Andreas Henriksson wrote: > On Sat, Aug 04, 2018 at 08:59:29AM +0200, Davide Prina wrote: > > $ xhost +si:localuser:temp > > $ su - temp Please note that this pattern gives the temp user the ability to log everything that you type into other X applications, and gives the temp user the ability to inject input into your other X applications. That is usually enough to let the temp user escalate privileges to those of the initiating user, defeating the purpose of using separate users. If you want privilege separation, X is unfortunately not the right tool. Consider using a separate X display (for example "Switch User" in GNOME, or the equivalent fast-user-switching feature in other desktop environments), or a "thicker" remoting layer like VNC, Spice or Xpra. It is also worth considering using ssh to localhost instead of su: ssh already needs to know about differing privilege, and "ssh -X -oForwardX11Trusted=no" might be able to mitigate the design issues in X. On Mon, 06 Aug 2018 at 17:31:35 +0200, Helge Kreutzmann wrote: > this change (requiring a DISPLAY=:0) is really suprising. I'v used su > for ages and a simple xhost + (yes, I know that this has security > implications) was sufficient. "xhost +" grants access to your display to *literally any user*, including special-purpose system users like "nobody" and the users that run network servers. Please avoid this pattern! If you need to grant unlimited access to your display to another user, at least use "xhost +si:localuser:$THEIR_USERNAME". (Or, again, consider using a separate X display, or Xpra, or similar.) > Plese document this in a public place, the best would be the man page > as that is where users are looking for (a NEWS entry would only catch > administrators once). > > I suggest putting it under NOTES. If you like, I can draft up a patch. Andreas already asked for a merge request, so it seems that proposing a patch would indeed be welcome. smcv
Processed: Re: Bug#905409: upgrade of util-linux and login break the xhost command for other users
Processing control commands: > retitle 905409 util-linux: "su -" no longer copies DISPLAY and XAUTHORITY to > child, but this is not documented Bug #905409 [util-linux] upgrade of util-linux and login break the xhost command for other users Changed Bug title to 'util-linux: "su -" no longer copies DISPLAY and XAUTHORITY to child, but this is not documented' from 'upgrade of util-linux and login break the xhost command for other users'. -- 905409: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905409 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#905409: upgrade of util-linux and login break the xhost command for other users
Hi Andreas, On 05/08/2018 05:40, Andreas Henriksson wrote: $ xhost +si:localuser:temp $ su - temp You are right that the old su would copy over DISPLAY and XAUTHORITY environment variables, even when you tell it to give you a new clean environment. probably this modification must be written in the changelog as an important change. $ firefox & Error: GDK_BACKEND does not match available displays The error message is a bit misleading. Please just try running this instead: DISPLAY=:0 firefox & thanks, this work :-) strange, one of the first things that I have done was: export DISPLAY=:0 probably I have mistake writing something :-( ... looking the history I found that I don't have write "export" :-( Please feel free to submit a merge request with a util-linux.NEWS entry addition mentioning the difference if you can come up with a nice user-understandable description. I'm not very good in English. I think you can close this bug. thanks for your help Davide
Bug#905409: upgrade of util-linux and login break the xhost command for other users
Hello Davide Prina, Thanks for your bug report. (Reply inline below.) On Sat, Aug 04, 2018 at 08:59:29AM +0200, Davide Prina wrote: > Package: util-linux > Version: 2.32-0.1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > upgrading > * util-linux:amd64 (2.32-0.1, 2.32-0.3) > * login:amd64 (1:4.5-1, 1:4.5-1.1) > > do not let work anymore something like this: > > $ xhost +si:localuser:temp > $ su - temp You are right that the old su would copy over DISPLAY and XAUTHORITY environment variables, even when you tell it to give you a new clean environment. The util-linux implementation does what you tell it to do. > $ firefox & > Error: GDK_BACKEND does not match available displays The error message is a bit misleading. Please just try running this instead: DISPLAY=:0 firefox & > > downgrade this two packages (as I have done now before writing this bug > report) solve the problem > > If I mistake and this is a login package problem please reassign the bug. Please feel free to submit a merge request with a util-linux.NEWS entry addition mentioning the difference if you can come up with a nice user-understandable description. You might also want to file a minor bug report against firefox (upstream?) to give a less misleading error message. Regards, Andreas Henriksson
Bug#905409: upgrade of util-linux and login break the xhost command for other users
Package: util-linux Version: 2.32-0.1 Severity: grave Justification: renders package unusable Dear Maintainer, upgrading * util-linux:amd64 (2.32-0.1, 2.32-0.3) * login:amd64 (1:4.5-1, 1:4.5-1.1) do not let work anymore something like this: $ xhost +si:localuser:temp $ su - temp $ firefox & Error: GDK_BACKEND does not match available displays downgrade this two packages (as I have done now before writing this bug report) solve the problem If I mistake and this is a login package problem please reassign the bug. thank Davide -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.17.8-dp-20180723 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages util-linux depends on: ii fdisk 2.32-0.3 ii libaudit1 1:2.8.3-1+b1 ii libblkid1 2.32-0.3 ii libc6 2.27-5 ii libmount1 2.32-0.3 ii libpam0g 1.1.8-3.7 ii libselinux12.8-1+b1 ii libsmartcols1 2.32-0.3 ii libsystemd0239-7 ii libtinfo6 6.1+20180714-1 ii libudev1 239-7 ii libuuid1 2.32-0.3 ii zlib1g 1:1.2.11.dfsg-1 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 4.1-2 ii kbd 2.0.4-4 pn util-linux-locales -- debconf information: util-linux/noauto-with-nonzero-passnum:
