kern/72922: linux emulation: suid/sgid threaded applications hang

[Andriy Gapon]

The following reply was made to PR kern/72922; it has been noted by GNATS.

From: Andriy Gapon <avg at icyb.net.ua>
To: Maxim Sobolev <sobomax at portaone.com>
Cc: freebsd-gnats-submit at 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