1

Is there a way to allow only a single main process to delete an original file?

Other processes may read and modify it, but not delete. I know a process can empty its contents but there is no problem with that as such a process will access it through human interaction.

The point is, the main process must not lose access to the inode. Ext4 is that way, right? It is not about absolute paths but inodes right?

Some processes, to provide safe writing, write a new file, delete or rename the original, then rename the new to the original and delete the original, but that causes the loss of the original inode and the main process doesn't try to recreate the file when appending to it. (the process could make a backup, compare and write the new things in the same inode but that isn't what is happening).

The main proccess ends up writing to nowhere apparently?

6
  • 1
    As long as a process keeps an fd open on the file, it will have access to that file (inode). But any process (with appropriate access) can remove the names to that inode, and I'm not sure you can link a "floating" "deleted" file back. The inode will still be reserved as long as the process keeps the file open... but I'm not sure if that really helps. What is it you're actually trying to do here?
    – ilkkachu
    Jan 30 at 20:19
  • @ilkkachu love to be proven wrong there, but I don't think there's a way to do that; that is something that people complain about; it's hard to exec* anything that's not accessible via a path. Jan 30 at 20:33
  • You could open a file in appending mode, which only allows the process to add additional data, but not removing data or deleting data/file.
    – paladin
    Jan 30 at 20:41
  • @paladin I think VeganEye tries to shoe-horn an immutable program in their access scheme, and isn't free to change the program and to design a log-structured file format that would allow for this kind of access pattern Jan 30 at 20:43
  • @ilkkachu: chattr +i would seem to be totally irrelevant here, since the OP wants “other processes” to be able to modify the file. Jan 31 at 2:22

3 Answers 3

1

is there a way to allow only a single main proccess to delete a original file?

No. File access is mediated through user id and group id, not per process.

You can of course just give your process a separate group id or run it as its own user, and that puts it in a separate "category" as any other process, and that allows you to define separate permissions for it.

no problem on that as such proccess will access it thru human interaction.

uh, that's not very logical - an interactive process might do exactly the same as a non-interactive, and typically has at least as many bugs ;)

Some proccesses, to provide safe writing, write a new file, delete or rename the original, then rename the new to the original and delete the original,

No! The opposite happens: they write to a new file, and rename the new file to the old file's name – that's atomic, and that's the reason they do it. At no point does the old file get deleted! During every moment in this procedure, there's exactly, not less, not more, 1 file with the right name.

Note that for any file access, where you do anything but appending a single write's worth of data, this atomic replacement is the only safe way to go! (Unless you want to do very funky things with locking structures; most file formats don't even allow for something like that!)

So, whatever you think you're solving there, it probably is good the way it is, and you need to find a different way to achieve what you wanted.

write the new things in the same inode

I sometimes wish the word "inode" would disappear! It's really just an implementation detail of the on-disk format of the file system, with which a user should never have to deal with. And it's kind of true: unless you're developing a file system, the moment you start caring about inodes, you're probably doing something wrong.

8
  • 1
    Re. that last paragraph, well, I think "inode" is a relevant term in userspace too, in as much as it means the file proper (and not just a name), the difference being rather significant in cases like this, or when comparing replacing a file by overwriting vs. renaming on top (or anything with hard links). Trying to make a strict difference between the phrases "file" and "filename" might be a bit confusing (similarly, "file descriptor" and "[open] file description" are rather too close to each other, IMO.)
    – ilkkachu
    Jan 30 at 20:43
  • 1
    Plus "inode" is already rooted in ls -i, and st_ino in struct stat, so we can't get rid of phrase anyway. (But I guess one could start using "identity number" instead, that should fit both.)
    – ilkkachu
    Jan 30 at 20:43
  • 1
    @ilkkachu agreed, it's kind of fuzzy what the ford "file" means, especially when one wonders whether it means the data that one could get access through as an fd or FILE*, the path, the fd or FILE that's currently being held, or the entry that combines extents on a storage device Jan 30 at 20:46
  • @ilkkachu re ls -i, st_ino: that's among these things that I think shouldn't exist: these numbers are practically useless: can't use it to do anything like opening or writing, can't use it to compare things (unless both stats where guaranteed to be executed at the same time, which isn't possible) Jan 30 at 20:48
  • 1
    AFAIK, checking st_ino (and st_dev along with it, I guess) is the only way to figure out if two files are the same (i.e. hard links to each other). So in a sense, it's the identity number. Though one could argue that hard links themselves are an obscure remnant that would be best removed. And yes, you can have races if you have concurrent modifications, but in that case, even if you could stat() two files at the same time (atomically), the data might be stale before you could use it. We'd need some rather more general way of locking files to get around that.
    – ilkkachu
    Jan 31 at 8:00
0

An “obvious” answer is “security through obscurity” (STO) — prevent the other processes from knowing the name of the file.

The question lacks any context or big picture of your software architecture.  Your usage of the phrase “main process” suggests that you have a parent process that opens the file and passes the file descriptor to child process(es).  If the “other processes” open the file independently, then they need to know its name, and this approach cannot be used.  Similarly, if the filename is hard-coded and “well known”, then this approach is not useful.

If you have a parent/child architecture with a variable filename, keep the name secret from the child processes.

It is possible to search for a file if you know its inode number.  You can thwart that attack vector by putting the file in a directory that's not publicly readable.

-3

You could do something like this:

First thing is, you disallow all other process - other than main process - to write to your file in any kind, example:

mv my_precious_file my_precious_file.original

Second, you create a hardlink to the file:

sudo ln my_precious_file.original my_precious_file.copy

Third, you allow your untrustworthly sub processes to acces the hardlinked file.

# DUMMY example, this is not code you shall execute,
# it's purpose is to show that a process might delete the original file,
# but now it can only delete the hard linked "copy" and not the "original"
# "Haha I'm a not trustworthly process." (Some people don't understand.)
cp my_precious_file.copy /dev/null && rm my_precious_file.copy

Your sub process can still delete the hard linked "copy", but the "original" will still remain "untouched".

If the hard linked "copy" has been "deleted" you just "recreate" it.

7
  • 2
    (1) How does this stop other processes from accessing the “original” file?  (2) You don't need sudo to hardlink (plain) files.  (3) What is cp my_precious_file.copy /dev/null? Perhaps you mean cp /dev/null my_precious_file.copy? Jan 31 at 2:20
  • Have you even read OPs original question/problem? @G-ManSays'ReinstateMonica' I hope you are not the one who has downvoted my answer, otherwise you make me very mad. I added sudo just in case, cause usually a user should not have direct access to such files. # haha I'm a not trustworthly process is an example of an not trustworthly process and cp my_precious_file.copy /dev/null && rm my_precious_file.copy is also a dummy placeholder for that not trustworthy process...
    – paladin
    Jan 31 at 3:14
  • 2
    @paladin couple of things: less aggression, please! I'm sure you don't mean it, but you're coming across slightly personal. Then, using sudo "just in case" is actually bad advise, both for "understanding why I'm doing something" reasons, and because not using sudo "just in case" is much safer. And: I don't understand what a cp my_precious_file.copy /dev/null would mean as "an example of a not trustworthy process". Jan 31 at 13:40
  • >> Some processes, to provide safe writing, write a new file, delete or rename the original, then rename the new to the original and delete the original, but that causes the loss of the original inode and the main process doesn't try to recreate the file when appending to it. (the process could make a backup, compare and write the new things in the same inode but that isn't what is happening). << PS You know what makes people upset? When other people have no idea and simple downvote something they don't understand. If they would at least provide constructive review or read OP question.
    – paladin
    Jan 31 at 14:43
  • OP has multiple process, which all write to the same file. Some of those process delete this file. OP cannot change the behavior of these processes directly, as they are probably hardcoded. OP asked if it's somehow possible to disallow certain processes from deleting a file, but still allowing them to write to the same file. My answer suggest to use multiple hardlinks to work around this problem. cp my_precious_file.copy /dev/null && rm my_precious_file.copy is just a placeholder, a dummy, which shall represent such process, which will delete the file. It is a metapher.
    – paladin
    Jan 31 at 14:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .