Date: Wed, 9 Mar 2005 11:00:14 GMT From: Andriy Gapon <avg@icyb.net.ua> To: emulation@FreeBSD.org Subject: Re: kern/72922: linux emulation: suid/sgid threaded applications hang Message-ID: <200503091100.j29B0EKv005562@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/72922; it has been noted by GNATS. From: Andriy Gapon <avg@icyb.net.ua> To: Maxim Sobolev <sobomax@portaone.com> Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/72922: linux emulation: suid/sgid threaded applications hang Date: Wed, 09 Mar 2005 12:57:49 +0200 on 09.03.2005 11:59 Maxim Sobolev said the following: > Hmm, that's pretty strange. Can you please fetch the following Linux > binary, make it suid root and try to run as ordinary user on your > system? I've used it to verify that my patch is in fact works - after > the change has been made it stopped hanging at my system. > > http://www.pbxpress.com/~sobomax/aqueue_linux > > It will make sense to execute that strmqm program under ktrace(8) with > -i flag (use ports/devel/linux_kdump to decode resulting trace) and send > me the output of linux_kdump. Maybe your version of linuxthreads uses > some different set of flags in linux_clone(), so that my heuristics fails. Maxim, 1. I've tried to follow your advice, but a new strange thing happened (or maybe it is not strange, but I never payed attention before): "-i" in "ktrace -i" doesn't work on suid/sgid applications, when run as normal user: # chmod 6550 ~/tmp/aqueue_linux # ls -l ~/tmp/aqueue_linux -r-sr-s--- 1 avg topspin 16804 9 ยลา 13:47 /home/avg/tmp/aqueue_linux $ ktrace -i ~avg/tmp/aqueue_linux -n 100 pusher started poper started $ linux_kdump > kdump.out $ cat kdump.out 16103 ktrace RET linux_brk 0 16103 ktrace CALL linux_olduname(0xbfbfea4e,0xbfbfe95c,0xbfbfe96c) 16103 ktrace NAMI "/home/avg/tmp/aqueue_linux" 16103 ktrace NAMI "/compat/linux/lib/ld-linux.so.2" If I set permission back to normal executable, "-i" works again. 2. "ktrace -i" works if executed as super-user and strmqm still hangs. Here's some relevant info, whcih makes things quite obvious: # egrep 'fork|exec|clone|kill|signal' kdump.out 79953 strmqm CALL linux_clone(0xf00,0x8099370) 79953 strmqm RET linux_clone 79954/0x13852 79954 strmqm RET linux_fork 0 79954 strmqm CALL linux_clone(0xf21,0xbf3ffbd0) 79954 strmqm RET linux_clone 79955/0x13853 79955 strmqm RET linux_fork 0 79954 strmqm CALL linux_kill(0x13851,0x20) 79954 strmqm RET linux_kill 0 79955 strmqm CALL linux_kill(0x13851,0x20) 79955 strmqm RET linux_kill 0 79955 strmqm CALL linux_kill(0x13851,0x20) 79955 strmqm RET linux_kill 0 79955 strmqm CALL linux_kill(0x13851,0x20) 79955 strmqm RET linux_kill 0 uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico 79954 strmqm CALL linux_clone(0xf21,0xbf1ffbd0) 79954 strmqm RET linux_clone 79956/0x13854 79956 strmqm RET linux_fork 0 79954 strmqm CALL linux_kill(0x13851,0x20) 79954 strmqm RET linux_kill 0 79956 strmqm CALL linux_kill(0x13851,0x20) 79956 strmqm RET linux_kill 0 79953 strmqm CALL linux_kill(0x13854,0x20) 79953 strmqm RET linux_kill 0 79956 strmqm CALL linux_kill(0x13851,0x20) 79956 strmqm RET linux_kill 0 79956 strmqm CALL linux_kill(0x13851,0x20) 79956 strmqm RET linux_kill 0 79953 strmqm CALL linux_kill(0x13853,0x1c) 79953 strmqm RET linux_kill RESTART permitted' from pthread_kill.) | ('1 - Operation not permitted' from pthread_kill.) | " "| Comment1 :- '1 - Operation not permitted' from pthread_kill. | 79954 strmqm CALL linux_kill(0x13854,0x21) 79954 strmqm RET linux_kill RESTART 79954 strmqm CALL linux_kill(0x13853,0x21) 79954 strmqm RET linux_kill RESTART Looks like signal 32 is OK, but there are 28 and 33 in addition to it. 33 seems to be another Linux real-time signal and is probably used with linux threads for some purpose. Here's what I read in signal(7) Linux man page: <<< Linux supports real-time signals as originally defined in the POSIX.4 real-time extensions (and now included in POSIX 1003.1-2001). Linux supports 32 real-time signals, numbered from 32 (SIGRTMIN) to 63 (SIGRTMAX). (Programs should always refer to real-time signals using notation SIGRTMIN+n, since the range of real-time signal numbers varies across Unices.) Unlike standard signals, real-time signals have no predefined meanings: the entire set of real-time signals can be used for application-defined purposes. (Note, however, that the LinuxThreads implementation uses the first three real-time signals.) >>>> So probably 32,33,34 should be subject to your patch. I am not sure what signal 28 (SIGWINCH?) is used for (in this case), but most probably it is not thread-related and not application critical, because execution continues after that signal, but an error message is logged. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200503091100.j29B0EKv005562>