The abstract socket on linux is independent on the fole system and has no file system representation. This is useful when the selinux rules prevents the /tmp directory. (using namespaces)
Created attachment 1889 [details] patch solving the problem
Comment on attachment 1889 [details] patch solving the problem Leaving aside the merits of the rest of the change, this part is trivially broken on any platform that isn't linux since "len" will be undefined: >+#ifdef linux >+ int len, ret; >+#endif >+ len = snprintf(buf, sizeof buf, _PATH_UNIX_X, dnr);
also, if snprintf fails it'll call memcpy with a length of -1 (cast to size_t) and probably overwrite something that you'd rather it didn't.
Created attachment 1890 [details] patch solving the problem
Created attachment 1891 [details] patch solving the problem
Hoping solved all problems.
Isn't the solution for SELinux rules breaking /tmp to fix the SELinux rules? Abstract sockets look like a complete trainwreck waiting to happen: a brand new, completely unstructured but shared namespace, with zero intrinsic security protections (not even filesystem permissions) where every consumer application must implement security controls correctly, rather than letting the kernel do it. At the very least, I think we will wait a while before rushing to add support for this to OpenSSH.
(In reply to comment #7) > Isn't the solution for SELinux rules breaking /tmp to fix the SELinux > rules? The namespaces create separate /tmp directories for each logged user. (and one for system also). There is no possibily to make system sockets under /tmp Abstract sockets look like a complete trainwreck waiting to > happen: a brand new, completely unstructured but shared namespace, with > zero intrinsic security protections (not even filesystem permissions) > where every consumer application must implement security controls > correctly, rather than letting the kernel do it. > > At the very least, I think we will wait a while before rushing to add > support for this to OpenSSH. Have you any other idea how safely solve this need?
(In reply to comment #7) ... namespace, with > zero intrinsic security protections (not even filesystem permissions) the file permissions of the whole /tmp/.X11.... is 0777 :D which is IMHO equivalent.
xorg xserver people are interested in abstract sockets support in ssh for connecting to X11 since they plan to disable (and possibly deprecate in future) tcp/unix sockets by default: http://lists.x.org/archives/xorg-devel/2014-September/043832.html http://lists.x.org/archives/xorg-devel/2014-September/043816.html http://lists.x.org/archives/xorg-devel/2014-September/043828.html
Hi jchadima@redhat.com, do you know the status of your patch? We use pam_namespace on Linux to namespace /tmp on multiuser systems and this could help us with X11 forwarding.