3 ms·

Sure there is; monitor the process and when it terminates remove permissions. It's not like the kernel doesn't have ABIs to do this. I'm sure its not _that_ si

• kccqzy 7y ago
  Which process? Remember you are usually (but not always) at the command line prompt to pass an argument when you drag things to the Terminal. You can't trivially find out the process(es) that gets run from there so you are tracking the shell. Do you wait till the shell exits? Many developers spend months in a single shell. What if the process forks? What if the process double-forks to become a daemon, and then Terminal quits? Who removes the xattr then when Terminal isn't even running? Does the kernel now remember that and need to do I/O when _exit(2) is called? What if the process forks and itself exits? Does the permission gets revoked upon the parent process's exit and the child process's access suddenly get revoked? If so, does the opened file descriptor still works or it becomes unusable? If the file descriptor still works even though the on-disk file doesn't contain the permission xattr, would the file descriptor still continue to have special access when transmitted over a UNIX socket to an unrelated process? Do you instead track the original PGID instead of PID? Then what if setpgid(2) is called? What if the system loses power and no one cleans up the permissions? Do you keep a log of files with such xattrs and clean them at next boot? What if at next boot the file system isn't mounted or mounted at a different mount point?