Linux – why new pid is smaller than the old ones

This sounds like a job for a Mandatory Access Control system like SELinux or AppArmor.

This article on SELinux will give you some idea of how powerful such systems can be, and the tools you need to develop such policies.

Beware, your wish to restrict access to all files is likely to backfire on you. In Unix "everything is a file," so entirely preventing all file access will prevent your program from even starting. A more productive approach will likely be to restrict file writing, either entirely or to only a specific directory, and to whitelist categories of files the program can legitimately read.

Another option is to use chroot or jails. With these OS features, instead of preventing file I/O or program execution, you would simply build a restricted environment where there is nothing sensitive for your untrusted program to read, write or execute. Your program could only operate on the files you put into the "box" with it.

The first number is the job index; job-related commands (jobs, fg, etc.) use them. So for example, if you get the output [2] 2847, you could run fg 2 to foreground that job.

As far as I could tell from skimming the source, there isn't a way to disable the message. The one check it does do is to ensure the shell is interactive, so if you run the command in a non-interactive shell you won't get that output. For example, you could run it in a subshell:

$ (your_command &)

That's equivalent to running the command in an entirely different shell though, so it might have other undesired side-effects

If you're willing to patch bash, you can just get rid of that particular output. In bash 4.2 it's in jobs.c on line 1428:

fprintf (stderr, "[%d] %ld\n", job + 1, (long)pid);

It gets called in other circumstances; if you just want it gone for this particular case, you can comment out execute_cmd.c, line 762:

DESCRIBE_PID (last_made_pid);