I have a process P which writes contents to a file F. I need to be able to dynamically enable/disable P to write to F. I tried changing the permissions for the user/group but this requires the process to be restarted(in fact the whole system). In the end I should be able to execute a "script" which does the following:

sleep 10  

and as a result P will be able to write for the first 10 seconds and not after that. I am using Debian distibution.

Is this possible?

Update: The real use case is that I am trying to filter a given process to write to a specific device file /dev/fb0 I have two processes which are writing to that file and I want to be able to determine exactly one of the two which is allowed to write to that file at a given moment without having to kill/stop the processes.

  • 3
    And assuming the process has the file open for writing at the time you do the DisablePWriteF what would you like to happen when the process attempts a write() system call? The write() to fail with an error (what error?)? The write() to appear as if it succeeded but did nothing? The process to be suspended? The write() to block until you run EnablePWriteF again? – Stéphane Chazelas Mar 15 '17 at 13:37
  • Are you also expecting to be able to prevent file modification being done through mmap()? – Stéphane Chazelas Mar 15 '17 at 13:42
  • @StéphaneChazelas I have explained in more detail my use case in a comment below ilkkachu's answer. Hope this makes it more clear. – Aleksandar Dimitrov Mar 15 '17 at 14:09
  • @ilkkachu , note taken. – Aleksandar Dimitrov Mar 15 '17 at 14:20
  • @AleksandarDimitrov, excellent! – ilkkachu Mar 15 '17 at 14:22

At least on my version of Linux, it looks like you may be able to use mandatory locks. I've only tested it with /dev/null, but I can't see any reason why it wouldn't work with other devices like your frame buffers:

As root:

mount -t tmpfs -o mand locked-fb some-dir
cp -a /dev/fb0 some-dir/fb0-for-process-A
cp -a /dev/fb0 some-dir/fb0-for-process-B
chmod g+s some-dir/fb0-for-process-[AB] # enable mand-lock

Then for instance, using perl and the File::FcntlLock module (or do it directly in C):

#! /usr/bin/perl
use File::FcntlLock;

$l = new File::FcntlLock;

open my $fba, '<', 'some-dir/fb0-for-process-A' or die$!;

sleep 10; # writing OK
$l->lock($fba, F_SETLK); # writing blocked on fb0-for-process-A

sleep 10;
exit; # lock now released (or do an explicit unlock)

Have one process open the fb0 device via the fb0-for-process-A file, and the other one via fb0-for-process-B and apply locking to both files to decide which process may write at a given time.


No, not really (as far as I know). The file access permissions are only checked when the file is opened (and there's no system call to revoke them), so if the process has a file handle with write permission, it has write permission.

(If you do a simple chmod on the file, you shouldn't need a restart. If you change for example group memberships, you do need to login again for the changes to take effect.)

What you could do, in general, would be to direct the output to a pipe, and have the reading end of the pipe control whether to handle (or forward) the data, or to discard it. (The later clarification about the use case being certain device files makes this a bit moot, though.)

  • Unfortunately my case is different. I am working with framebuffers, I have two applications drawing on the screen and the drawing commands are written in a file /dev/fb0 I want to be able to control the data flow to that file depending on the process id which is writing. I have no control over the applications which are writing. – Aleksandar Dimitrov Mar 15 '17 at 14:07
  • Strictly speaking, with recent versions of Linux you could use seals to forbid writing (with EPERM) after the file has been open. mandatory locks can also be used to block writes. Though neither could be used in this particular use case. – Stéphane Chazelas Mar 15 '17 at 14:31
  • What I can find on a quick look seems to imply that sealing files is only possible for shmfs backed files or memfd's. (unless things have changed even more recently.) In any case, giving back the permission without the process having to reopen the file might be problematic. (and dropping an error would likely cause the program to bail out.) – ilkkachu Mar 15 '17 at 14:36
  • It looks like it may be possible to use mandatory locks after all – Stéphane Chazelas Mar 15 '17 at 15:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.