# Protect application files in from access by the same user

I want to know if it's possible for an application to create files accessible only from the application itself. Problem is that I don't have root access.

For example, if I run the application as UserA I want to ensure that any other application run by UserA cannot access the files.

-
Do you want to prevent root-access, too? –  Nils Feb 3 '12 at 21:00
No I don't want to prevent root access. But, if I run the application as UserA I want also that any other application runned from UserA cannot access the files. I think that something like creating a dummy user for the application would be what I need, but I don't have root access. –  Simone Feb 3 '12 at 21:37
can you manage the information in memory instead of writing it to a file? That would effectively prevent something from writing to it. –  Dennis Hodapp Feb 4 '12 at 17:02

If you set the permissions on the files to: 0600 or set the umask 077 for the user running the application the files will only be accessible by the application user and root.

-
This has nothing to do with the question... –  Chris Down Feb 7 '12 at 14:46
It did in it's original form. –  Karlson Feb 7 '12 at 15:00

In times past, and in systems without proc(5) mounted, a process could create and open a file, unlink(2) it, and have a valid, open handle to an anonymous file. No other process could name and therefore could not open(2) the file, even another process run by the same user (or root)

However, as most Linux systems have /proc mounted, even nameless files retain a name like /proc/2757/fd/4 which is accessible to the other processes run by the same user.

-

I currently cant think of a way to achieve what you want without involving root. So: Contact your sysadmin and get a second account for your application.

-
I can't. This is an homework project and should run on the teacher pc and he explicitly said that the application should never ask for root access. –  Simone Feb 3 '12 at 22:01
I suspect you either misunderstand the assignment or your instructor is not aware that the request is impossible to satisfy using conventional means. (Or, much less likely, the instructor knows of a non-standard, non-portable, method to make this work in a limited circumstance and wants to see if you can puzzle out the trick from thin air (I've seen more masochistic assignments, so it is possible but I think the first two guesses far more likely). –  msw Feb 6 '12 at 14:44

This isn't possible directly; however, you could create a program (or a wrapper to that program) that checks information about its parent.

-

It is impossible for an unprivileged process to create a file that it can read but other processes running as that user cannot.

Proof: suppose process A (unprivileged) has the file open, and process B (running as the same user) wants to open the file as well. Process B can call ptrace to take control of process A. The ptrace system call lets process B execute arbitrary code inside process A, including establishing a unix socket to process A and passing the open file descriptor over it (file descriptor passing is a feature of unix datagram sockets that, as the name indicates, allows the sender to send a file descriptor to the receiver, after which the receiver has the same file open in the same mode).

It's possible that what your professor intended is to open a file then delete it. A deleted file — technically, an unlinked file — cannot be opened by conventional means: No process (even a privileged one) can open it with the open system call, since there is no name that could be passed as an argument. But the process (or processes) that has the file open can continue working with it; the file will only actually be deleted when the last process that has it open dies. Other processes can still open a handle to the file by using ptrace as described above.

In addition to the ptrace method, on some unix variants including Linux, there may be other ways to open a file that's opened in another process, through /proc`.

-