Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

parent / child processes

Name: Anonymous 2009-05-01 11:21

Process A creates another process B. Process A then dies, but process B still has the PID of process A marked as its parent process. Later on, a process C starts and is randomly assigned the PID that process A was originally assigned.

Are there any security or other implications of this happening?

Name: Anonymous 2009-05-01 11:30

A fatal error occured!
Please post threads less often!FUCKING HELL I REMEMBER WHEN SOMEONE SPAMMED /PROG/ AND RUINED IT FOR EVERYONE NOW I CAN NEVER MAKE NEW THREADS Powered by Shiichan 3955 + 4chan 20080608.

Name: Anonymous 2009-05-01 11:48

In any real operating system, a new process can never be created with the PID of any previously existing process.

Name: Anonymous 2009-05-01 12:09

>>3
Name me one of these operating systems, and how this works.

Name: Anonymous 2009-05-01 12:18

I thought init (PID 1) adopted any orphaned child process?

Name: Anonymous 2009-05-01 13:08

>>5 this.

Name: Anonymous 2009-05-01 13:40

>>3
PIDs are generated sequentially on *NIX systems and re-start at zero after all numbers have been exhausted. pid_t is 32 bit (or 64 bit on x64 systems). Assume you'd spawn 100000 processes a day, your system would still need to have an uptime of 60 years before the PID generation starts at zero again.

Show me any system that runs for even a year straight and we'll talk about security implications of repeating PIDs again.

Name: Anonymous 2009-05-01 13:43

>>7
My pids are 16-bit.
Linux 2.6

Name: Anonymous 2009-05-01 14:01

>>8

$ uname -r
2.6.27
$ echo "#include <sys/types.h>
#include <stdio.h>
int main() { printf(\"sizeof(pid_t): %d bit\n\", sizeof(pid_t) * 8); }" | gcc -xc -o test - && ./test
sizeof(pid_t): 32 bit

Name: Anonymous 2009-05-01 14:04

>>7
My pids are 16.6-bit.

__
Sent from my iPhone

Name: Anonymous 2009-05-01 14:14

>>10
Shannon is rolling in his grave

Name: Anonymous 2009-05-01 14:17

>>9
Doesn't stop your kernel from cycling pids over 2^16.

Name: Anonymous 2009-05-01 16:07

>>1
you got it wrong. in *nix at least, a child process does not inherit that parent's process number; it has its own and the parent process continues to exist as a "zombie" process until the child process is done as well, after which the OS cleans it up. it's impossible for something to "inherit" the parent process' pid.

Name: Anonymous 2009-05-01 16:08

>>13
You seem to have misinterpreted all of those words.

Name: Anonymous 2009-05-01 16:14

You can get races with programs that deliver signals (killall, for example).

Name: Anonymous 2009-05-01 18:59

In Windows, child processes maintain a link back to the parent process. If the parent dies, this information isn't updated, however this isn't a problem since nothing relies on that information being present.

Name: Bill Gates III 2009-05-02 7:01

>>13 >>16
Windows is better in this regard:
'nothing relies on that information'
"process continues to exist as a "zombie" process until the child process is done as well"

Name: Anonymous 2009-05-02 8:08

>>17
Unix was created in the last 60's, so obviously it's going to be naturally inferior to the glorious Windows NT architecture.

Name: Anonymous 2009-05-02 8:09

>>17,17
Amateur quoter.

Name: Anonymous 2009-05-02 8:10

>>18
These trolls don't even try!

Name: WINNT ARCHITECTURE FAN 2009-05-02 12:33

>>18
FOR GLORY! EN TARO ADUN

Name: Anonymous 2009-05-02 19:37

>>19
I was able to troll you, wasn't I?

Name: Anonymous 2009-05-02 22:16

>>22
i don't think anyone on /prog/ gets properly Troll'd anymore. it's just Trolls replying to Troll posts because there's no other option. hell, without the Troll replies, there'd be no /prog/ at all!

Name: Troll Warlord 2009-05-12 17:01

Am I a troll?
...
Is there an echo in here !!!

Name: Anonymous 2009-05-12 17:18

tampopo desu lol

Name: Anonymous 2009-05-12 20:15

>>20
It's not a troll. NT really does have a superior architecture and design. To give one excellent example, look at NTFS permissions compared to the ones your standard Unix filesystem. So much more flexible and with beautiful hierarchy.

Name: Anonymous 2009-05-12 20:54

>>26
That's the only thing anyone can actually ever point out as being better. No go off and defrag your NTFS partitions, they need it.

Name: Anonymous 2009-05-12 21:04

>>27
EXT3 filesystems become fragmented too.

Name: Anonymous 2009-05-12 21:09

>>28
Not as badly as NTFS though. And BSD's UFS/FFS is even better.

Don't change these.
Name: Email:
Entire Thread Thread List