I've seen a few comments in IRC and elsewhere wondering my CDE needs to have rpcbind run in insecure (-i) mode, so I thought I would explain the problem a little bit.
CDE uses Tooltalk, an RPC based interprocess communications system. It's sort of an older, more primitive d-bus. As part of logging into CDE, the ttsession program is started. This program is your session tooltalk server. It is started as your user (no privs). ttsession, via a a function it defines, gettransient(), attempts to contact rpcbind (the RPC portmapper) to allocate a temporary 'program number' and 'register' it with the RPC subsystem. It then exports the program number to child processes, so that other CDE programs in your session can contact your ttsession. In order for ttsession to register itself, it needs to use the pmap_set() function. For security reasons, it is generally not advisable to let any old program from a remote machine on your network register RPC services. The rpcbind manpages say that its insecure (-i) mode is only required when attempting to register a service over the LAN, and that using the loopback interface (localhost) is ok. But, the manpage lies. In reality, not only does the request have to come from the loopback interface (which ttsession is already attempting), it must also come from a reserved port (<1024). Root privs are required to allocate reserved ports, so therefore ttsession fails. Making ttsession run suid root is not gonna happen. Running with -i, does allow other hosts on your LAN to also register with the portmapper, which is not something most people will want (and extremely few would ever need). rpcbind, in theory, can also allow pmap_set() over a named filesystem socket (/run/rpcbind.sock) without requiring any privs. This would also be a solution, but unfortunately glibc's pmap_* routines know nothing about this transport, and I do not know how to make the pmap routines use it. Perhaps someone with more in-depth RPC and portmapper experience could clue us in. So, 'rpcbind -i' it is. Here is a link to a bug report against fedora describing the problem. At the bottom is a message containing a patch to rpcbind allowing connections from non-privleged ports. Apparently this patch has made it 'upstream', a couple years ago, but at least my ubuntu/kubuntu systems do not have it. If you loath using -i, then pester your dist's rpcbind maintainers, or get the source for rpcbind and apply this patch. https://bugzilla.redhat.com/show_bug.cgi?id=731542 The Signed-off-by's imply that both redhat and perhaps suse have this patch applied, but I have niether of those OS's, so someone else will have to check them. Good luck! -- Jon Trulson "If the Martian rope-a-dope don't get him, he'll get himself, he'll come in too fast and punch himself out." - one of my brothers, referring to the Curiosity landing. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
