Date: Thu, 31 May 2001 13:03:52 +0000 (GMT) From: diman <diman@asd-g.com> To: Jiangyi Liu <gzjyliu@public.guangzhou.gd.cn> Cc: freebsd-hackers@FreeBSD.ORG Subject: FIX needed. Was: Weird PT_DETACH Message-ID: <Pine.BSF.4.21.0105311233490.266-300000@portal.none.ua> In-Reply-To: <Pine.BSF.4.21.0105301250460.202-100000@portal.none.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--0-868826533-991314232=:266
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hello, guys.
Jiangui Liu told right thing - next code fragment
creates a SIGKILL immune allproc entry:
--begin------------------------------------------------------
#include <sys/types.h>
#include <sys/ptrace.h>
#include <unistd.h>
#include <signal.h>
int main() {
ptrace(PT_TRACE_ME, 0, 0, 0);
puts("never kill me");
execve("/bin/sh", NULL, NULL);
}
--end-------------------------------------------------------
Ok, lets see..
> ./im
[1]+ Stopped ./im
> ps -O flags -p 473
PID F TT STAT TIME COMMAND
473 5806 v1 TX 0:00.00 (sh)
>
We have:
flags = 0x05806 = P_CONTROLT | P_INMEM | P_TRACED | P_WAITED | P_EXEC
state = SSTOP
In such state SIGKILL never will be delivered (+1000 kern_sig.c)
Attached is an *attempt* to fix the problem - please
expertise and correct me (patch made against 4.1.1R)
Another problem(?) Jiangui found considers PT_DETACH ptrace(2)
call. While i'm attaching to a running process via PT_ATTACH,
PT_DETACH works well as expected.
If i instead use PT_TRACE_ME -> execve -> PT_DETACH,
child always got killed by SIGTRAP.
I'm not sure it's a bug - needs play a bit more with gdb... ..
Attached is a simple program i used for tests.
Note that Jiangyi Liu reported same effects on 4.3-S.
Sorry Jiangyi Liu, I wrong understood you yesterday -
needs more more more sleeping :~)
Best Regards.
> On 30 May 2001, Jiangyi Liu wrote:
>
> > Hi all,
> >
> > The ptrace(2) man page is probably outdated. I used PT_DETACH in the
> > following code, but it didn't run ./test. I also tried to use
> > ptrace(PT_DETACH, pid, (caddr_t)1, 0) to detach, but it failed too.
> >
> > BTW, if I omit wait(0) and ptrace(PT_DETACH, ...) in the code, after
> > it runs there is a process sticking to the system. Even kill -9 can't
> > kill it.
> >
> > $ ps aux | grep jyliu
> > ...
> > jyliu 423 0.0 0.1 216 100 p2 TX 7:41AM 0:00.00 (test)
> > ...
> > $ kill -9 423
> > $ ps aux | grep jyliu
> > ...
> > jyliu 423 0.0 0.1 216 100 p2 TX 7:41AM 0:00.00 (test)
> > ...
> >
> > So it's still there. Quite funny. Any clue?
> >
> > Jiangyi
> >
> > ---code begins here
> > #include <unistd.h>
> > #include <sys/types.h>
> > #include <sys/ptrace.h>
> >
> > int main()
> > {
> > pid_t pid;
> >
> > if(!(pid=fork())) {
> > /* child */
> > ptrace(PT_TRACE_ME, 0, 0, 0);
> > puts("child speaking");
> > execve("./test", NULL, NULL);
> > } else {
> > wait(0);
> > ptrace(PT_DETACH, pid, 0, 0);
> > exit(0);
> > }
> > }
> > ---code ends here
--0-868826533-991314232=:266
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dd.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.BSF.4.21.0105311303520.266@portal.none.ua>
Content-Description:
Content-Disposition: attachment; filename="dd.c"
I2luY2x1ZGUgPHVuaXN0ZC5oPg0KI2luY2x1ZGUgPHN5cy90eXBlcy5oPg0K
I2luY2x1ZGUgPHN5cy9wdHJhY2UuaD4NCiNpbmNsdWRlIDxzeXMvd2FpdC5o
Pg0KI2luY2x1ZGUgPHNpZ25hbC5oPg0KDQppbnQgbWFpbihpbnQgYWMsIGNo
YXIgKiphdikgew0KCXBpZF90IHBpZD0wOw0KCWludCBzLCAJCWk9MDsNCiAg
ICAgDQoJaWYgKCBhYyA+IDEpIHsNCgkJcGlkID0gYXRvaSggYXZbMV0gKTsN
CgkJDQoJCWlmICggMCA+IHB0cmFjZShQVF9BVFRBQ0gscGlkLDAsMCkgKSB7
DQoJCQlwcmludGYoImNhbid0IGF0dGFjaCB0byAlZFxuIixwaWQpOw0KIAkJ
CWV4aXQoMCk7DQogCQl9DQogCQkNCiAgICAgCX0gZWxzZQ0KICAgICAJCXBp
ZCA9IGZvcmsoKTsNCiAgICAgCQ0KCWlmICggIXBpZCApIHsgLyogY2hpbGQg
LSB1bnJlYWNoZWQgaWYgYXR0YWNoaW5nIG1vZGUgKi8NCiANCiAgICAgICAg
IAkvKiBzbGVlcCBhIGJpdCB0byBtYWtlIHBhcmVudCBhYmxlIGlzc3VlIHdh
aXQgKi8NCgkJdXNsZWVwKDEwMDAwMCk7DQoJCXB0cmFjZShQVF9UUkFDRV9N
RSwgMCwgMCwgMCk7DQogCQ0KIAkJcHV0cygiLS0gY2hpbGQgc3BlYWtpbmci
KTsNCgkJZXhlY3ZlKCIvYmluL2RmIiwgTlVMTCwgTlVMTCk7DQoJDQoJfSBl
bHNlIC8qICAgIHdhaXQgZm9yIGNoaWxkL2luZmVyaW9yICAgICovDQoJDQoJ
ICB3aGlsZSAoIDAgPCB3YWl0cGlkKHBpZCwmcywwKSApIHsNCg0KCQlpZiAo
IFdJRlNJR05BTEVEKHMpICkgew0KCQkJcHJpbnRmKCItLSAlZCBleGl0ZWQg
JXNcbiIsDQoJCQlwaWQsIFdDT1JFRFVNUChzKSA/ICJjb3JlIGR1bXBlZCI6
ICIiICk7DQoJCQlleGl0KDApOw0KCQl9DQoNCg0KCQlpZiAoIFdJRkVYSVRF
RChzKSApIHsNCgkJCXByaW50ZigiLS0gJWQgZXhpdGVkIHdpdGggc3RhdHVz
ICVkXG4iLAlcDQoJCQlwaWQsIFdFWElUU1RBVFVTKHMpICk7DQoJCQlleGl0
KDApOw0KCQl9DQoNCgkJaWYgKCBXSUZTVE9QUEVEKHMpICkgew0KDQoJCQlw
cmludGYoIi0tICVkIHN0b3BwZWQgb24gc2lnbmFsICVkXG4iLAlcDQoJCQlw
aWQsIFdTVE9QU0lHKHMpICk7DQoJCQkNCgkJCWlmKCAhaSApIHsNCgkJCQlw
cmludGYoIi0tIFBUX0NPTlRJTlVFIGl0Li5cbiIpOw0KCQkJCXB0cmFjZShQ
VF9DT05USU5VRSwgcGlkLCAoY2FkZHJfdCkxLCAwKTsNCgkJCX0gZWxzZSB7
DQoJCQkJcHJpbnRmKCItLSBQVF9ERVRBQ0ggaXQuLlxuIik7DQoJCQkJcHRy
YWNlKFBUX0RFVEFDSCwgcGlkLCAoY2FkZHJfdCkxLCBTSUdDT05UKTsNCgkJ
CX0NCgkJCWkgKys7DQoNCgkJfSBlbHNlDQoJCQlwcmludGYoIi8qIG5vdCBy
ZWFjaGVkICovXG4iKTsJDQoNCgl9DQp9DQoNCg0KDQo=
--0-868826533-991314232=:266
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="kern_sig.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.BSF.4.21.0105311303521.266@portal.none.ua>
Content-Description:
Content-Disposition: attachment; filename="kern_sig.patch"
KioqIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fc2lnLmMub2xkCVRodSBNYXkg
MzEgMTI6MjU6NTIgMjAwMQ0KLS0tIC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5f
c2lnLmMJVGh1IE1heSAzMSAxMjoxOToxOSAyMDAxDQoqKioqKioqKioqKioq
KioNCioqKiAxMTIwLDExMzYgKioqKg0KICANCiAgCWNhc2UgU1NUT1A6DQog
IAkJLyoNCiAgCQkgKiBJZiB0cmFjZWQgcHJvY2VzcyBpcyBhbHJlYWR5IHN0
b3BwZWQsDQogIAkJICogdGhlbiBubyBmdXJ0aGVyIGFjdGlvbiBpcyBuZWNl
c3NhcnkuDQogIAkJICovDQogIAkJaWYgKHAtPnBfZmxhZyAmIFBfVFJBQ0VE
KQ0KICAJCQlnb3RvIG91dDsNCiAgDQotIAkJLyoNCi0gCQkgKiBLaWxsIHNp
Z25hbCBhbHdheXMgc2V0cyBwcm9jZXNzZXMgcnVubmluZy4NCi0gCQkgKi8N
Ci0gCQlpZiAoc2lnID09IFNJR0tJTEwpDQotIAkJCWdvdG8gcnVuZmFzdDsN
CiAgDQogIAkJaWYgKHByb3AgJiBTQV9DT05UKSB7DQogIAkJCS8qDQotLS0g
MTEyMCwxMTM3IC0tLS0NCiAgDQogIAljYXNlIFNTVE9QOg0KICAJCS8qDQor
IAkJICogS2lsbCBzaWduYWwgYWx3YXlzIHNldHMgcHJvY2Vzc2VzIHJ1bm5p
bmcuDQorIAkJICovDQorIAkJaWYgKHNpZyA9PSBTSUdLSUxMKQ0KKyAJCQln
b3RvIHJ1bmZhc3Q7DQorIA0KKyAJCS8qDQogIAkJICogSWYgdHJhY2VkIHBy
b2Nlc3MgaXMgYWxyZWFkeSBzdG9wcGVkLA0KICAJCSAqIHRoZW4gbm8gZnVy
dGhlciBhY3Rpb24gaXMgbmVjZXNzYXJ5Lg0KICAJCSAqLw0KICAJCWlmIChw
LT5wX2ZsYWcgJiBQX1RSQUNFRCkNCiAgCQkJZ290byBvdXQ7DQogIA0KICAN
CiAgCQlpZiAocHJvcCAmIFNBX0NPTlQpIHsNCiAgCQkJLyoNCg==
--0-868826533-991314232=:266--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0105311233490.266-300000>