[Touch-packages] [Bug 1784499] Re: AppArmor treats regular NFS file access as network op
See also https://lists.ubuntu.com/archives/apparmor/2018-October/011823.html -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1784499 Title: AppArmor treats regular NFS file access as network op Status in apparmor package in Ubuntu: Confirmed Bug description: I am using AppArmor 2.12-4ubuntu5 on Ubuntu 18.04/bionic. I have the usr.bin.man profile enforced, and home directories in NFS. The log excerpt copied below is the result of a single invocation of "man ls" by an unprivileged user. (The program did display the man page correctly to the user.) It does not seem appropriate for AppArmor to report the man(1) program as having attempted to contact the NFS server directly, when it only tried to access an NFS-served file in the normal way. "man" is not a network-aware program and the log below misleadingly implies otherwise. Jul 30 17:38:35 darkstar kernel: [69963.052243] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.052274] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.052297] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.052314] kauditd_printk_skb: 34 callbacks suppressed Jul 30 17:38:35 darkstar kernel: [69963.052316] audit: type=1400 audit(1532986715.854:214): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.052323] audit: type=1400 audit(1532986715.854:215): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=802 faddr=10.24.115.84 fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.052327] audit: type=1400 audit(1532986715.854:216): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.052339] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.052363] audit: type=1400 audit(1532986715.854:217): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.052364] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.052369] audit: type=1400 audit(1532986715.854:218): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=802 faddr=10.24.115.84 fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.052386] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.052450] audit: type=1400 audit(1532986715.854:219): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.059570] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.059640] audit: type=1400 audit(1532986715.862:220): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.061907] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.061925] audit: type=1400 audit(1532986715.862:221): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2792 comm="less" laddr=X.X.X.X lport=719 faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.062006] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.062014] audit: type=1400 audit(1532986715.862:222): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2792 comm="less" laddr=X.X.X.X lport=719 faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.066404] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.066434] audit: type=1400 audit(1532986715.866:223): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2788 comm="man" laddr=X.X.X.X lport=719 faddr=Y.Y.Y.Y fport=2049
[Touch-packages] [Bug 1784499] Re: AppArmor treats regular NFS file access as network op
AppArmor really should restrict NFS access only via the file-path rules, not via the network rules, since if an application accesses a file via NFS, all related network traffic is initiated and controlled by the kernel (or by kernel helper processes like automount, rpc.gssd and nfsidmap), and not by the application. Workaround (for /usr/bin/man only): Add to /etc/apparmor.d/local/usr.bin.man the lines # TCP/UDP network access for NFS network inet stream, network inet6 stream, network inet dgram, network inet6 dgram, then run # systemctl reload apparmor This really should be fixed in the kernel, but until then, perhaps adding a widely-included /etc/apparmor.d/abstractions/nfs with the above lines would be useful, as /usr/bin/man is just one example of an affected application. See also bug #1662552 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1784499 Title: AppArmor treats regular NFS file access as network op Status in apparmor package in Ubuntu: Confirmed Bug description: I am using AppArmor 2.12-4ubuntu5 on Ubuntu 18.04/bionic. I have the usr.bin.man profile enforced, and home directories in NFS. The log excerpt copied below is the result of a single invocation of "man ls" by an unprivileged user. (The program did display the man page correctly to the user.) It does not seem appropriate for AppArmor to report the man(1) program as having attempted to contact the NFS server directly, when it only tried to access an NFS-served file in the normal way. "man" is not a network-aware program and the log below misleadingly implies otherwise. Jul 30 17:38:35 darkstar kernel: [69963.052243] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.052274] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.052297] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.052314] kauditd_printk_skb: 34 callbacks suppressed Jul 30 17:38:35 darkstar kernel: [69963.052316] audit: type=1400 audit(1532986715.854:214): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.052323] audit: type=1400 audit(1532986715.854:215): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=802 faddr=10.24.115.84 fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.052327] audit: type=1400 audit(1532986715.854:216): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.052339] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.052363] audit: type=1400 audit(1532986715.854:217): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.052364] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.052369] audit: type=1400 audit(1532986715.854:218): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=802 faddr=10.24.115.84 fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.052386] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.052450] audit: type=1400 audit(1532986715.854:219): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.059570] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.059640] audit: type=1400 audit(1532986715.862:220): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2781 comm="man" laddr=X.X.X.X lport=719 faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send" Jul 30 17:38:35 darkstar kernel: [69963.061907] nfs: RPC call returned error 13 Jul 30 17:38:35 darkstar kernel: [69963.061925] audit: type=1400 audit(1532986715.862:221): apparmor="DENIED" operation="sendmsg" profile="/usr/bin/man" pid=2792 comm="less" laddr=X.X.X.X lport=719 faddr=Y.Y.Y.Y fport=2049 family="inet" sock_type="stream" protocol=6
[Touch-packages] [Bug 1648107] Re: $XAUTHORITY should move into $XDG_RUNTIME_DIR
LightDM is already able to create the xauthority file locally under $XDG_RUNTIME_DIR, using configuration option user-authority-in-system- dir. This option is off by default on Ubuntu 16.04/18.04, but can be enabled with # echo -e '[LightDM]\nuser-authority-in-system-dir=true' >/etc/lightdm/lightdm.conf.d/50-user-authority-in-system-dir.conf LightDM then sets XAUTHORITY=/var/run/lightdm/$USER/xauthority instead of $HOME/.Xauthority. However, this path goes through the symbolic link /var/run -> /run. For some reason (why?) snap does not like such symlinks, resulting in a warning: # snap install pdftk # pdftk 2018/08/24 17:32:48.267771 cmd_run.go:442: WARNING: XAUTHORITY environment value is not a clean path: "/run/lightdm/mgk25/xauthority" A workaround to canonicalize the XAUTHORITY path (to eliminate symlinks) can be installed with e.g. # echo 'XAUTHORITY=`readlink -f "$XAUTHORITY"` && [ -z "$XAUTHORITY" ] && export XAUTHORITY' >/etc/X11/Xsession.d/10canonicalize-xauthority It would be nicer if LightDM directly used a canonical path in XAUTHORITY with user-authority-in-system-dir=true, or if snap didn't have to be so picky about symbolic links. (LightDM currently does not set ICEAUTHORITY when user-authority-in- system-dir=true.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1648107 Title: $XAUTHORITY should move into $XDG_RUNTIME_DIR Status in lightdm package in Ubuntu: Triaged Bug description: Historically, the X authority file was placed into $HOME/.Xauthority such that X11 clients on remote servers could access it in environments in which $HOME is located on a network file system. Today, this practice has become an anachronism that causes far more problems than it solves: a) Remote X11 clients are typically started today via "ssh -X", which emulates its own X11 server port $DISPLAY and therefore always creates its own X authority file entry on the remote server. Therefore, there is no longer any practical benefit from having the X authority file located in $HOME. b) If $HOME is on a network file system that implements "root squash", then commands such as "sudo xterm" or "sudo wireshark" won't work to start an X client with root privileges, as root is not able to read ~/.Xauthority via NFS. :-( c) If $HOME is on a network file system with Kerberos authentication, then users can easily get locked out by their screensavers once the Kerberos ticket expires. This is because some screen lockers (e.g., gnome-screensaver) invoke a separate utility (e.g., /usr/lib/gnome- screensaver/gnome-screensaver-dialog) in order to ask the user of a locked screen for their password. Such a tool needs to access $XAUTHORITY right before it can display the password prompt, which will fail if the user's Kerberos ticket has expired (e.g. because a machine was suspended for 24 hours and therefore the ticket was not refreshed automatically on time). Without the ability to ask for a password, the screensaver then cannot call pam_krb5 to renew the user's Kerberos ticket, and the user remains locked out in a deadlock situation. :-( Both b) and c) are regular reasons for support requests in educational/corporate Linux environments with $HOME on Kerberized NFS. The solution is simple. Instead of $HOME/.Xauthority, just use in future $XDG_RUNTIME_DIR/xauthority as the location of the X authority file. (In case $XDG_RUNTIME_DIR/ does not exist, /tmp/xauthority-$USER might be a suitable fallback option.) According to https://standards.freedesktop.org/basedir-spec/basedir- spec-latest.html the $XDG_RUNTIME_DIR has all the right properties for holding the X authority file: it is always located in a local tmpfs filesystem, guaranteed to be accessible only to the current user, and will be wiped when the user has closed all sessions. On modern Linux systems, pam_systemd usually creates XDG_RUNTIME_DIR=/run/user/$UID, and wipes it in the end. (Note that according to https://standards.freedesktop.org/basedir-spec /basedir-spec-latest.html you should set the "sticky bit" on any files created in $XDG_RUNTIME_DIR whose timestamp is not updated regularly.) Feature request: please provide an option for LightDM to do the equivalent of export XAUTHORITY=$XDG_RUNTIME_DIR/xauthority chmod +t $XAUTHORITY and encourage Linux distribution maintainers to set this option by default, such that ~/.Xauthority is no longer used. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1648107/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1648107] Re: $XAUTHORITY should move into $XDG_RUNTIME_DIR
see also bug 685194 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1648107 Title: $XAUTHORITY should move into $XDG_RUNTIME_DIR Status in lightdm package in Ubuntu: Triaged Bug description: Historically, the X authority file was placed into $HOME/.Xauthority such that X11 clients on remote servers could access it in environments in which $HOME is located on a network file system. Today, this practice has become an anachronism that causes far more problems than it solves: a) Remote X11 clients are typically started today via "ssh -X", which emulates its own X11 server port $DISPLAY and therefore always creates its own X authority file entry on the remote server. Therefore, there is no longer any practical benefit from having the X authority file located in $HOME. b) If $HOME is on a network file system that implements "root squash", then commands such as "sudo xterm" or "sudo wireshark" won't work to start an X client with root privileges, as root is not able to read ~/.Xauthority via NFS. :-( c) If $HOME is on a network file system with Kerberos authentication, then users can easily get locked out by their screensavers once the Kerberos ticket expires. This is because some screen lockers (e.g., gnome-screensaver) invoke a separate utility (e.g., /usr/lib/gnome- screensaver/gnome-screensaver-dialog) in order to ask the user of a locked screen for their password. Such a tool needs to access $XAUTHORITY right before it can display the password prompt, which will fail if the user's Kerberos ticket has expired (e.g. because a machine was suspended for 24 hours and therefore the ticket was not refreshed automatically on time). Without the ability to ask for a password, the screensaver then cannot call pam_krb5 to renew the user's Kerberos ticket, and the user remains locked out in a deadlock situation. :-( Both b) and c) are regular reasons for support requests in educational/corporate Linux environments with $HOME on Kerberized NFS. The solution is simple. Instead of $HOME/.Xauthority, just use in future $XDG_RUNTIME_DIR/xauthority as the location of the X authority file. (In case $XDG_RUNTIME_DIR/ does not exist, /tmp/xauthority-$USER might be a suitable fallback option.) According to https://standards.freedesktop.org/basedir-spec/basedir- spec-latest.html the $XDG_RUNTIME_DIR has all the right properties for holding the X authority file: it is always located in a local tmpfs filesystem, guaranteed to be accessible only to the current user, and will be wiped when the user has closed all sessions. On modern Linux systems, pam_systemd usually creates XDG_RUNTIME_DIR=/run/user/$UID, and wipes it in the end. (Note that according to https://standards.freedesktop.org/basedir-spec /basedir-spec-latest.html you should set the "sticky bit" on any files created in $XDG_RUNTIME_DIR whose timestamp is not updated regularly.) Feature request: please provide an option for LightDM to do the equivalent of export XAUTHORITY=$XDG_RUNTIME_DIR/xauthority chmod +t $XAUTHORITY and encourage Linux distribution maintainers to set this option by default, such that ~/.Xauthority is no longer used. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1648107/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1648107] Re: $XAUTHORITY should move into $XDG_RUNTIME_DIR
While we are at it, we could probably also set ICEAUTHORITY=$XDG_RUNTIME_DIR/ICEauthority in a similar fashion, as this is the equivalent cookie facility for X11 client-client communication. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1648107 Title: $XAUTHORITY should move into $XDG_RUNTIME_DIR Status in lightdm package in Ubuntu: Triaged Bug description: Historically, the X authority file was placed into $HOME/.Xauthority such that X11 clients on remote servers could access it in environments in which $HOME is located on a network file system. Today, this practice has become an anachronism that causes far more problems than it solves: a) Remote X11 clients are typically started today via "ssh -X", which emulates its own X11 server port $DISPLAY and therefore always creates its own X authority file entry on the remote server. Therefore, there is no longer any practical benefit from having the X authority file located in $HOME. b) If $HOME is on a network file system that implements "root squash", then commands such as "sudo xterm" or "sudo wireshark" won't work to start an X client with root privileges, as root is not able to read ~/.Xauthority via NFS. :-( c) If $HOME is on a network file system with Kerberos authentication, then users can easily get locked out by their screensavers once the Kerberos ticket expires. This is because some screen lockers (e.g., gnome-screensaver) invoke a separate utility (e.g., /usr/lib/gnome- screensaver/gnome-screensaver-dialog) in order to ask the user of a locked screen for their password. Such a tool needs to access $XAUTHORITY right before it can display the password prompt, which will fail if the user's Kerberos ticket has expired (e.g. because a machine was suspended for 24 hours and therefore the ticket was not refreshed automatically on time). Without the ability to ask for a password, the screensaver then cannot call pam_krb5 to renew the user's Kerberos ticket, and the user remains locked out in a deadlock situation. :-( Both b) and c) are regular reasons for support requests in educational/corporate Linux environments with $HOME on Kerberized NFS. The solution is simple. Instead of $HOME/.Xauthority, just use in future $XDG_RUNTIME_DIR/xauthority as the location of the X authority file. (In case $XDG_RUNTIME_DIR/ does not exist, /tmp/xauthority-$USER might be a suitable fallback option.) According to https://standards.freedesktop.org/basedir-spec/basedir- spec-latest.html the $XDG_RUNTIME_DIR has all the right properties for holding the X authority file: it is always located in a local tmpfs filesystem, guaranteed to be accessible only to the current user, and will be wiped when the user has closed all sessions. On modern Linux systems, pam_systemd usually creates XDG_RUNTIME_DIR=/run/user/$UID, and wipes it in the end. (Note that according to https://standards.freedesktop.org/basedir-spec /basedir-spec-latest.html you should set the "sticky bit" on any files created in $XDG_RUNTIME_DIR whose timestamp is not updated regularly.) Feature request: please provide an option for LightDM to do the equivalent of export XAUTHORITY=$XDG_RUNTIME_DIR/xauthority chmod +t $XAUTHORITY and encourage Linux distribution maintainers to set this option by default, such that ~/.Xauthority is no longer used. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1648107/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1648107] Re: $XAUTHORITY should move into $XDG_RUNTIME_DIR
As a workaround, install the attached shell script as /etc/X11/Xsession.d/10local-xauthority It uses xauth to merge ~/.Xauthority into $XDG_RUNTIME_DIR/xauthority and then updates XAUTHORITY to point at that location. (Note that the "xauth merge" command will leave a warning such as "xauth: file /run/user/1597/xauthority does not exist" in ~/.xsession- errors.) In the long run, it would of course be more elegant if LightDM (and other display managers) created the X authority file there in the first place. ** Attachment added: "/etc/X11/Xsession.d/10local-xauthority" https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1648107/+attachment/4789021/+files/local-xauthority -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1648107 Title: $XAUTHORITY should move into $XDG_RUNTIME_DIR Status in lightdm package in Ubuntu: Triaged Bug description: Historically, the X authority file was placed into $HOME/.Xauthority such that X11 clients on remote servers could access it in environments in which $HOME is located on a network file system. Today, this practice has become an anachronism that causes far more problems than it solves: a) Remote X11 clients are typically started today via "ssh -X", which emulates its own X11 server port $DISPLAY and therefore always creates its own X authority file entry on the remote server. Therefore, there is no longer any practical benefit from having the X authority file located in $HOME. b) If $HOME is on a network file system that implements "root squash", then commands such as "sudo xterm" or "sudo wireshark" won't work to start an X client with root privileges, as root is not able to read ~/.Xauthority via NFS. :-( c) If $HOME is on a network file system with Kerberos authentication, then users can easily get locked out by their screensavers once the Kerberos ticket expires. This is because some screen lockers (e.g., gnome-screensaver) invoke a separate utility (e.g., /usr/lib/gnome- screensaver/gnome-screensaver-dialog) in order to ask the user of a locked screen for their password. Such a tool needs to access $XAUTHORITY right before it can display the password prompt, which will fail if the user's Kerberos ticket has expired (e.g. because a machine was suspended for 24 hours and therefore the ticket was not refreshed automatically on time). Without the ability to ask for a password, the screensaver then cannot call pam_krb5 to renew the user's Kerberos ticket, and the user remains locked out in a deadlock situation. :-( Both b) and c) are regular reasons for support requests in educational/corporate Linux environments with $HOME on Kerberized NFS. The solution is simple. Instead of $HOME/.Xauthority, just use in future $XDG_RUNTIME_DIR/xauthority as the location of the X authority file. (In case $XDG_RUNTIME_DIR/ does not exist, /tmp/xauthority-$USER might be a suitable fallback option.) According to https://standards.freedesktop.org/basedir-spec/basedir- spec-latest.html the $XDG_RUNTIME_DIR has all the right properties for holding the X authority file: it is always located in a local tmpfs filesystem, guaranteed to be accessible only to the current user, and will be wiped when the user has closed all sessions. On modern Linux systems, pam_systemd usually creates XDG_RUNTIME_DIR=/run/user/$UID, and wipes it in the end. (Note that according to https://standards.freedesktop.org/basedir-spec /basedir-spec-latest.html you should set the "sticky bit" on any files created in $XDG_RUNTIME_DIR whose timestamp is not updated regularly.) Feature request: please provide an option for LightDM to do the equivalent of export XAUTHORITY=$XDG_RUNTIME_DIR/xauthority chmod +t $XAUTHORITY and encourage Linux distribution maintainers to set this option by default, such that ~/.Xauthority is no longer used. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1648107/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1648107] [NEW] $XAUTHORITY should move into $XDG_RUNTIME_DIR
Public bug reported: Historically, the X authority file was placed into $HOME/.Xauthority such that X11 clients on remote servers could access it in environments in which $HOME is located on a network file system. Today, this practice has become an anachronism that causes far more problems than it solves: a) Remote X11 clients are typically started today via "ssh -X", which emulates its own X11 server port $DISPLAY and therefore always creates its own X authority file entry on the remote server. Therefore, there is no longer any practical benefit from having the X authority file located in $HOME. b) If $HOME is on a network file system that implements "root squash", then commands such as "sudo xterm" or "sudo wireshark" won't work to start an X client with root privileges, as root is not able to read ~/.Xauthority via NFS. :-( c) If $HOME is on a network file system with Kerberos authentication, then users can easily get locked out by their screensavers once the Kerberos ticket expires. This is because some screen lockers (e.g., gnome-screensaver) invoke a separate utility (e.g., /usr/lib/gnome- screensaver/gnome-screensaver-dialog) in order to ask the user of a locked screen for their password. Such a tool needs to access $XAUTHORITY right before it can display the password prompt, which will fail if the user's Kerberos ticket has expired (e.g. because a machine was suspended for 24 hours and therefore the ticket was not refreshed automatically on time). Without the ability to ask for a password, the screensaver then cannot call pam_krb5 to renew the user's Kerberos ticket, and the user remains locked out in a deadlock situation. :-( Both b) and c) are regular reasons for support requests in educational/corporate Linux environments with $HOME on Kerberized NFS. The solution is simple. Instead of $HOME/.Xauthority, just use in future $XDG_RUNTIME_DIR/xauthority as the location of the X authority file. (In case $XDG_RUNTIME_DIR/ does not exist, /tmp/xauthority-$USER might be a suitable fallback option.) According to https://standards.freedesktop.org/basedir-spec/basedir- spec-latest.html the $XDG_RUNTIME_DIR has all the right properties for holding the X authority file: it is always located in a local tmpfs filesystem, guaranteed to be accessible only to the current user, and will be wiped when the user has closed all sessions. On modern Linux systems, pam_systemd usually creates XDG_RUNTIME_DIR=/run/user/$UID, and wipes it in the end. (Note that according to https://standards.freedesktop.org/basedir-spec /basedir-spec-latest.html you should set the "sticky bit" on any files created in $XDG_RUNTIME_DIR whose timestamp is not updated regularly.) Feature request: please provide an option for LightDM to do the equivalent of export XAUTHORITY=$XDG_RUNTIME_DIR/xauthority chmod +t $XAUTHORITY and encourage Linux distribution maintainers to set this option by default, such that ~/.Xauthority is no longer used. ** Affects: lightdm (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1648107 Title: $XAUTHORITY should move into $XDG_RUNTIME_DIR Status in lightdm package in Ubuntu: New Bug description: Historically, the X authority file was placed into $HOME/.Xauthority such that X11 clients on remote servers could access it in environments in which $HOME is located on a network file system. Today, this practice has become an anachronism that causes far more problems than it solves: a) Remote X11 clients are typically started today via "ssh -X", which emulates its own X11 server port $DISPLAY and therefore always creates its own X authority file entry on the remote server. Therefore, there is no longer any practical benefit from having the X authority file located in $HOME. b) If $HOME is on a network file system that implements "root squash", then commands such as "sudo xterm" or "sudo wireshark" won't work to start an X client with root privileges, as root is not able to read ~/.Xauthority via NFS. :-( c) If $HOME is on a network file system with Kerberos authentication, then users can easily get locked out by their screensavers once the Kerberos ticket expires. This is because some screen lockers (e.g., gnome-screensaver) invoke a separate utility (e.g., /usr/lib/gnome- screensaver/gnome-screensaver-dialog) in order to ask the user of a locked screen for their password. Such a tool needs to access $XAUTHORITY right before it can display the password prompt, which will fail if the user's Kerberos ticket has expired (e.g. because a machine was suspended for 24 hours and therefore the ticket was not refreshed automatically on time). Without the ability to ask for a password, the screensaver then cannot call pam_krb5 to renew the user's Kerberos ticket, and the user
[Touch-packages] [Bug 1604010] Re: sntp missing
General comment: I would not consider "Use of uninitialized value" warnings in Perl on their own as evidence of a lack of software quality. If a Perl programmer deliberately used the fact that undef also works as an empty string, I would still consider that to be a perfectly legitimate Perl programming style. Such warnings often occur only because some 'warnings zealot' had added a '-w' option to the shebang line without also putting in the then essential "no warnings 'uninitialized';" pragma required for this Perl programming style. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1604010 Title: sntp missing Status in NTP: New Status in ntp package in Ubuntu: Triaged Bug description: In Ubuntu 16.04, the binary file /usr/bin/sntp is missing from the package ntp. The associated man page /usr/share/man/man1/sntp.1.gz is still included. How to reproduce: $ sudo apt-get install ntp $ dpkg-query -L ntp | grep sntp /usr/share/man/man1/sntp.1.gz Expected result: /usr/bin/sntp was included in Ubuntu 14.04: $ dpkg-query -L ntp | grep sntp /usr/bin/sntp /usr/share/man/man1/sntp.1.gz The sntp program remains a very useful tool for interactively testing on the command line the offset of the local clock to a remote NTP server (like "ntpdate -qu [ntp-server]" previously). It should be included in the same package as its man page. To manage notifications about this bug go to: https://bugs.launchpad.net/ntp/+bug/1604010/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1604010] [NEW] sntp missing
Public bug reported: In Ubuntu 16.04, the binary file /usr/bin/sntp is missing from the package ntp. The associated man page /usr/share/man/man1/sntp.1.gz is still included. How to reproduce: $ sudo apt-get install ntp $ dpkg-query -L ntp | grep sntp /usr/share/man/man1/sntp.1.gz Expected result: /usr/bin/sntp was included in Ubuntu 14.04: $ dpkg-query -L ntp | grep sntp /usr/bin/sntp /usr/share/man/man1/sntp.1.gz The sntp program remains a very useful tool for interactively testing on the command line the offset of the local clock to a remote NTP server (like "ntpdate -qu [ntp-server]" previously). It should be included in the same package as its man page. ** Affects: ntp (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1604010 Title: sntp missing Status in ntp package in Ubuntu: New Bug description: In Ubuntu 16.04, the binary file /usr/bin/sntp is missing from the package ntp. The associated man page /usr/share/man/man1/sntp.1.gz is still included. How to reproduce: $ sudo apt-get install ntp $ dpkg-query -L ntp | grep sntp /usr/share/man/man1/sntp.1.gz Expected result: /usr/bin/sntp was included in Ubuntu 14.04: $ dpkg-query -L ntp | grep sntp /usr/bin/sntp /usr/share/man/man1/sntp.1.gz The sntp program remains a very useful tool for interactively testing on the command line the offset of the local clock to a remote NTP server (like "ntpdate -qu [ntp-server]" previously). It should be included in the same package as its man page. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1604010/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 946322] Re: Add ICMP/IGMP protocols to cli tool
** Also affects: ufw (Ubuntu) Importance: Undecided Status: New ** No longer affects: ufw (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/946322 Title: Add ICMP/IGMP protocols to cli tool Status in ufw - Uncomplicated Firewall: Confirmed Bug description: Would it be possible to add ICMP IGMP to the protocols ufw can use? There are ways around it and it isn't needed often but it can be handy and it would be nice for completeness' sake. To manage notifications about this bug go to: https://bugs.launchpad.net/ufw/+bug/946322/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
