dumpable | Serialization without any serialization codes in C | Serialization library

I don't want others to be able to read this process data from /proc. Is there some alternative way to do this?

The contents of the per-process subdirectories in /proc are ordinarily owned by the effective uid and effective gid of the corresponding process. The only documented condition in which that's different is when the process's dumpable attribute has a value different from 1.

The reason I want this is that I have a program which runs as a regular user and reads sensitive data (passwords) from stdin

If the program in question runs as a regular user that you can choose, then the easiest thing to do is to choose a for-purpose user with a private primary group. For the purpose of /proc access, that should be about as good as setting the process non-dumpable or running it as root. Maybe better, if the process wants to be able to read from its own /proc entry. This is pretty natural, too. It does not, however, serve the primary purpose of turning off the dumpable flag -- i.e. to prevent the process from dumping core.

If the program itself is under your control, then you can simply modify it to issue an appropriate prctl() call. I suppose that this is not your case.

Otherwise, the program cannot be modified and must be runnable by arbitrary users. According to the prctl() documentation, there are four ways other than calling prctl() to cause a process's dumpable flag to be turned off:

• The process's effective user or group ID is changed.

• The process's filesystem user or group ID is changed (see credentials(7)).

• The process executes (execve(2)) a set-user-ID or set- group-ID program, resulting in a change of either the effective user ID or the effective group ID.

• The process executes (execve(2)) a program that has file capabilities (see capabilities(7)), but only if the permitted capabilities gained exceed those already permitted for the process.

These all describe situations in which the process is differently affected by access controls than ordinary processes started by the same user, which comes back around to my original suggestion of arranging for appropriate access control simply by controlling the user as which the program runs. After all, who cares if a random user runs the program and is able to retrieve secrets that they themselves entered? An issue arises only if other people can be tricked into divulging secrets to the program. But if you're considering this alternative then you've already rejected the easy option.

With the program ultimately being launched by a non-privileged user, changing its effective or filesystem credentials, even via a wrapper program, is not a viable alternative by itself. You're left, then, with making the program SUID or SGID, or assigning it capabilities that you can rely on differing from the user's normal ones. Note that the SUID / SGID target, if you go that way, does not need to be root; it just needs to be different from the user's own. This does, however, return again to having a designated identity for the program to run as.

The capabilites option requires your system to support capabilities, of course. If it doesn't then SUID / SGID is your only remaining option. Both of these are controlled by attributes attached to the program binary in the filesystem, so they do not require you to modify the program itself.