You've just misunderstood what it is you're doing.
It's easier if we work backwards, so what exactly is it that you want to do?
>I want to execute my own code on a system on which I do not have permissions to do so
How are you going to go about that?
>Find a process running on said system that will let me talk to it and make it do my bidding
How are you going to make it do what you want?
This is where it gets a bit complicated.
One thing you could do is find a buffer overflow bug in the process that lets you write data arbitrarily into its address space. However you can't write text (code) there because all the text pages are not writeable, only data, and the kernel will refuse to execute anything that isn't marked as executable text. So now we need to get creative.
What if we knew beforehand or could find out the text of the entire compiled binary and where it is in memory? This might be really hard or trivial depending on the target. Say we use this information to create a list of gadgets. Gadgets are one instruction followed by a return instruction. How does this help us? On an x86 compatible RET will pop an address from the stack and jump to it, and we can write shit to the stack! So now we can recreate our own code by piecing together instructions that are already in the program, writing their addresses out in one long line on the stack, and they'll get executed in the order we define. We can now execute arbitrary code inside the exploitable process.
This is return-oriented-programming. Repeat ad nauseum.
Note all the protections in place here making us jump through a heap of hoops. Memory is not linear. It appears so because of virtual trickery. Memory is mapped from physical addresses to virtual addresses and each process gets its own address space, which is like a private view of the world. Whenever you want to access a page of memory the MMU on the CPU will ask the hypervisor (kernel) what physical page to map to this virtual page address. If the kernel tells it nothing then it traps and produces a fault that will probably result in the process being terminated. All processes, including the kernel, are separated this way. They cannot see the contents of each others address space unless the information is given voluntarily.
Whenever you want to escalate your privileges you need to attack a process that already have the privileges you want (be it code execution on a remote system or root access on a local one). It's designed this way precisely to ensure that you do NOT need to trust all software on your system to be perfect for it to be safe.