On Fri, Jan 26, 2007 at 10:57:52AM +0100, Joerg Schilling wrote: > Nicolas Williams <Nicolas.Williams at Sun.COM> wrote: > > I lied. One more off-topic post: a psetenv(1) proc util might be a nice > > way to deal with PATH management in a shell-neutral, dot-file avoiding > > way. > > How do you like to implement this and correctly handle the memory allocation > in the other process?
The proc tools tend to work by using something called an "agent thread" to execute code in the victim process. The execution environment of agent thread code is very, very, very barebones: there's no linker, no loader, no allocator, nothing, and you have to download the code to run to the agent thread and such code usually just makes system calls (with all other threads in that process stopped). All this is so that the proc tool can run code in the victim without having to trust any code in the victim's address space, which is very important from a security point of view. The most obvious way to make psetenv(1) work would require enhancing the agent thread environment so that for _some_ tasks (where security is not an issue, and I think modifying the victim's environ is one such task) one could load code and link it with the application's link map list. I can think of other options. E.g., treating PATH as very special and using a system call to track its value (putenv(3C)/getenv(3C) would know what to do and the usual proc tool agent thread scheme would work just fine). (BTW, a special rtld for agent threads would make it a lot easier to write proc tools too, but wouldn't help in this case since modifying the victim's environ kinda requires being linked with the victim's libc.) Nico --
