|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: Re: Here's another glibc env. var.
From: Alan Cox (alan
lxorguk.ukuu.org.uk)Date: Fri May 26 2000 - 17:53:00 CDT
- Next message: Alan Cox: "Re: Here's another glibc env. var."
- Previous message: Kragen Sitaker: "Re: Here's another glibc env. var."
- In reply to: Pavel Kankovsky: "Re: Here's another glibc env. var."
- Next in thread: Chris Evans: "Re: Here's another glibc env. var."
- Next in thread: harada
obunsha.co.jp: "Re: Here's another glibc env. var."
- Reply: Alan Cox: "Re: Here's another glibc env. var."
- Reply: Chris Evans: "Re: Here's another glibc env. var."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> Let me explain an idea I had recently: whenever execve() is called on a
> s[ug]id binary, the kernel would load and run a specified "wrapper"
Keep the kernel out of it. If you want to do this add yourself an
ld-sanitize.so and make that your elf loader for such apps. No kernel help
needed
- Next message: Alan Cox: "Re: Here's another glibc env. var."
- Previous message: Kragen Sitaker: "Re: Here's another glibc env. var."
- In reply to: Pavel Kankovsky: "Re: Here's another glibc env. var."
- Next in thread: Chris Evans: "Re: Here's another glibc env. var."
- Next in thread: harada
obunsha.co.jp: "Re: Here's another glibc env. var."
- Reply: Alan Cox: "Re: Here's another glibc env. var."
- Reply: Chris Evans: "Re: Here's another glibc env. var."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]