[CRIU] Changing process environ, euid

[rektide at voodoowarez.com]

Hello,

What means does CRIU use to set up a process environ? I'm hoping there is some wisdom this particular
instrumentation group can lend, and I'm hoping there's some really bad nasty awful means to manipulate environ
of a running process. I'm also curious about how euid is setup, and whether there's any available ways to
instrument a process euid in linux?

There are dozens of questions about this on Stackoverflow and on the net. These are two of the most maximally
helpful pieces of guidances I've seen; 
http://unix.stackexchange.com/questions/38205/change-environment-of-a-running-process
http://superuser.com/questions/56884/change-euid-of-running-process

Forgive me for the ask for an education lesson, but I'd like to wade further into asking for being set straight-
Are char*'s returned by getenv() or environ() something one could modify directly, if in-advisably? If so, could
one cross-memory-attach that memory space? Will there be any buffer in the user memory space before or after the
environs segment?

What is up with euid? How and where is that retained and how does criu deal with that? I was shocked that I was
unable to come up with any userspace way to see a processes euid. I was kind of expecting a /proc/n/euid or some
such. One unanswered ask:
http://stackoverflow.com/questions/26515924/find-effective-id-euid-for-process-with-pid-some-number

---

Fluff text:

I do realize that 99.99999% of programs are going to have a bad time, and everyone who doesn't know that:
whatever you are trying to do is probably going to blow up badly. I'd like to see how far one could make it. I
lvoe the idea of CRIU, which allows warmed, loaded programs to be checkpointed off and spawned in multiple from
that save, but I'd also love to be able to meddle with the instances I'm spawning. My interpretation of CRIU is
that it captures state, possibly stores it, and then restores it, so I'm hoping you are the people who might be
able to help me figure out how to "restore" a particular (hacked) state into a program.

And I'm hoping to build a program which can find a way to expect and deal with it's environs/euid being modified.

Longstanding dream of mine:
I think it'd be awesome to take a complex program many users on a system run, and to be able to have a launcher
that takes that STOP'ed program, clones an instance (I could do this via some signalling between launcher and
the program forking itself, having forked copies be the thing the launcher manipulates for users), and has the
clone (here a forked child intended to be the user's) tweaked.

I've always thought superuser processes are dumb- which would be the normal way to do this- and would love to see
Linux have advanced it's instrumentation suite to a point where there are APIs on tap to allow external processes
(userspace processes) to meddle with system-bits in naughts/careful/cute ways: that way the application code 
doesn't have to live alongside securitization code.

My impression of CRIU is that much of the project has been getting means to report and modify what are normally
protected low level bits. I'm hoping that 'better instrumentation' story is true. That's why I'm writing and if
anyone wants to disabuse me of any of these above notions that's great, go ahead; even if negative it's still a
contribution, and I need some to get by bearings; thanks for you help, thanks for the amazing work CRIU-

-rektide