Computing desk
< May 2	<< Apr \| May \| Jun >>	May 4 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

May 3[edit]

Any way to set up a directory so that files can be created & written to once, but not be rewritten or deleted afterward?[edit]

Is there a way to set up a directory in Linux in such a way that a file can be created in the directory (and be written to) only if there's no file with the same name in the directory? After the newly created file is closed, it should not be possible to rewrite or delete it, except by a privileged user. --134.242.92.97 (talk) 16:22, 3 May 2017 (UTC)[reply]

A small program could store a backup directory which is write-protected, overwrite any file that gets modified by a normal user, and update the backup whenever a privileged user modifies a file. So yes, it's possible. Whether or not that's something you could do with just the OS depends on the OS. (I don't believe there's any way of doing it in Windows without requiring the cooperation of the normal users). ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 16:33, 3 May 2017 (UTC)[reply]

Windows NTFS rights differ in write which means create and alter which means modify. Under Linux i think about a cron job, sheduled every 15 mins or less chmodding or chowning all existing files in the folder to read only. --Hans Haase (有问题吗) 18:08, 3 May 2017 (UTC)[reply]

What would happen if the cron job chmod's a file to read-only while it's open? Will the program that has file open still be able to write to it? --134.242.92.97 (talk) 18:30, 3 May 2017 (UTC)[reply]

The write would succeed anyway. -- Finlay McWalter··–·Talk 19:03, 3 May 2017 (UTC)[reply]

Correct, to elaborate: the file's permissions are checked when the process callsopen(). If open() succeeds, it gives the process a file descriptor, and as long as the FD remains open, the process can then (assuming the file was opened R/W) read/write to/from the file as much as it wants regardless of later changes to the file's permissions or the process's user/group. This facilitates the very common practice of a process starting as root, opening files/sockets/etc. that only root has access to, and then changing its own user/group to a normal user, for increased security. Lots of daemons and system utilities (e.g., ping(1)) do this. --47.138.161.183 (talk) 20:07, 3 May 2017 (UTC)[reply]

Maybe someone can think of something clever, but failing that it should be possible to build a filesystem with the property you want using Filesystem in Userspace (using, for example, fuse.py). Mostly you could implement what you want as a passthrough, with only special handling in the open() and creat() ; if the underlying backing filesytem is root-only. But I do appreciate that "oh, just write a filesystem" is not a trivial suggestion. -- Finlay McWalter··–·Talk 19:09, 3 May 2017 (UTC)[reply]

On thinking further, a check would also be needed in at least truncate(), unlink(), and probably rename() -- Finlay McWalter··–·Talk 19:15, 3 May 2017 (UTC)[reply]

I just found this article on TechRepublic and it turns out Hans Haase is absolutely right. So you should be able to simply allow everyone to write and read, while withholding full control for the privileged users. You can thus clearly see that I am, in fact, a master Windows network admin. There's a trout button on my talk page for anyone who feels the need to rub it in. ᛗᛁᛟᛚᚾᛁᚱPants Tell me all about it. 19:13, 3 May 2017 (UTC)[reply]

What is your end goal? Beware the XY problem. --47.138.161.183 (talk) 19:58, 3 May 2017 (UTC)[reply]

That's a good point. If the purpose is to log actions, in a way that even the logging process cannot later alter (e.g. if it is later compromised), then syslog (especially network syslog to a remote machine) achieves this. From an application's perspective, syslog is write but not delete or overwrite, which sounds similar to the OP's goals. -- Finlay McWalter··–·Talk 20:18, 3 May 2017 (UTC)[reply]

Another approach is this. Set permissions on the directory so that only the owner can write on it. Create a new user ID and make it the owner of the directory. To write files, use a program which is owned by that user ID and is setuid. The rules about creating a new file every time and never writing to an existing file are embedded in this program (and as soon as it opens a file it removes write permission). Race conditions from two copies of the program running at once could be a problem, but not if they are forced to be unique. This could be forced by making every filename include both a timestamp and the process ID of the program creating it (and the hostname where it is running, if multiple hosts could write to the same directory). --76.71.6.254 (talk) 21:35, 3 May 2017 (UTC)[reply]

What you want sounds like what you get on a writable CD or DVD, once you write it, it is there. Just make sure you do not use a R/W disk. Graeme Bartlett (talk) 12:42, 5 May 2017 (UTC)[reply]