5 ms·

> access permissions are also properties of the embedding in the directory, rather than the bits of the file itself. No, in POSIX they are properties of the fi

by jwilk 9y ago

> access permissions are also properties of the embedding in the directory, rather than the bits of the file itself. No, in POSIX they are properties of the file. You can use fchmod() and fchown() to change mode and ownership via an fd. > A neat trick here is that you can effectively still access the file (even restore it) if a process has the file open, through the /proc filesystem. Yes, you can access them; but I don't believe you can link them. (But I'd love to proven wrong. A few years ago I actually needed to un-unlink a non-regular file that was still open.)

dfox 9y ago
You certainly cannot un-unlink file by linking the pseudofile in /proc somewhere, as that would involve cross-filesystem hardlinks. But it is probably possible to write simple kernel module that would allow you to do that through some non-standard interface.
- andrewla 9y ago
  I don't think the cross-filesystem hardlink is the problem, since the link in proc is a symbolic link. I can do this experimentally by creating a symbolic link in /tmp (a different filesystem) to a file in /home, and then creating a hard link (with ln -L) from the symbolic link to another file in /home, and the result is a valid hardlink to the same inode as the original file. This doesn't work through /proc for an unlinked file, but only because the underlying link call requires a path, not an inode. You can create a hard link out of proc if the file has not been deleted, though, without any cross-filesystem problems.
  - dfox 9y ago
    You have to somehow increment inode's reference count and write reference to it into some directory. symlink() does not increase reference count of anything and in fact its target does not have to be meaningful filename at all (although in the practical non-POSIX sense there does not exist any string that is not valid filename). One interesting ab-use of this is that you can use symlink()/readlink() as ad-hoc key-value store with atomicity guarantees (that hold true even on NFS). For example emacs uses exactly this for it's file locking mechanism. IIRC the files in /proc/pid/fd are not true symlinks but something that behaves as both file (you can do same IO operations as on the original FD) and symlink (ie. you can readlink() them and get some string) at once.
    - zokier 9y ago
      man 2 open section about O_TMPFILE seems to strongly imply that you can linkat from /proc/<pid>/fd to concrete file. Not sure if there are some special cases for /proc/self/fd vs /proc/<pid>/fd, but that would seem bit odd. http://man7.org/linux/man-pages/man2/open.2.html http://man7.org/linux/man-pages/man2/open.2.html edit: nevermind, seems like O_TMPFILE is the one that has been special-cased here, from man 2 linkat: > This will generally not work if the file has a link count of zero (files created with O_TMPFILE and without O_EXCL are an exception). http://man7.org/linux/man-pages/man2/linkat.2.html http://man7.org/linux/man-pages/man2/linkat.2.html :(
- daurnimator 9y ago
  Yes you can. linkat(AT_FDCWD, "/proc/self/fd/N", destdirfd, newname, AT_SYMLINK_FOLLOW); Will do it. This is the longest-available `flink` syscall method. See https://lwn.net/Articles/562488/ https://lwn.net/Articles/562488/ Sadly the AT_EMPTY_PATH change was backed out between 3.11-rc7 and release. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v3.11&id=f0cc6ffb8ce8961db587e5072168cac0cbc25f05 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
  - jwilk 9y ago
    As pointed out in another comment, this doesn't work when the link count is 0: $ uname -rv 4.15.0-3-amd64 #1 SMP Debian 4.15.17-1 (2018-04-19) $ touch foo $ exec 3<>foo $ rm foo $ ls -l /proc/$$/fd/3 lrwx------ 1 jwilk jwilk 64 Apr 25 10:02 /proc/324/fd/3 -> '/home/jwilk/foo (deleted)' $ strace -e linkat ln -L /proc/$$/fd/3 foo linkat(AT_FDCWD, "/proc/3447/fd/3", AT_FDCWD, "foo", AT_SYMLINK_FOLLOW) = -1 ENOENT (No such file or directory) ln: failed to create hard link 'foo' => '/proc/3447/fd/3': No such file or directory $ sudo strace -e linkat ln -L /proc/$$/fd/3 foo linkat(AT_FDCWD, "/proc/3447/fd/3", AT_FDCWD, "foo", AT_SYMLINK_FOLLOW) = -1 ENOENT (No such file or directory) ln: failed to create hard link 'foo' => '/proc/3447/fd/3': No such file or directory +++ exited with 1 +++
    - deleted 9y ago
      [deleted]
    - daurnimator 9y ago
      Unless you use `O_TMPFILE` without `O_EXCL` to create the file. open("/tmp", O_RDWR|O_TMPFILE, 0666) = 3 linkat(3, "", AT_FDCWD, "/tmp/bar", AT_EMPTY_PATH) = 0
andrewla 9y ago
That's interesting about the access permissions and ownership; I thought that access permissions in POSIX were path-dependent. Some quick experimentation indicates that ownership and access does in fact apply across hard links. There's still some truth to the path-dependent notion, in that you may not be able to access a file through a hard link in a directory that you do not have access to, even if you have access to that same hard link through another path. But if you don't have access to the file itself then you're out of luck. This does make sense from a security perspective, but I thought that the path-dependent checks in the kernel were strong enough to not require inode-associated ACLs. You're right about restoring the file by re-linking to the hard link, but you can access the contents and cp it out of proc at least.
Rapzid 9y ago
I believe you may be able to relink the inode with debugfs, depending on the filesystem.
nemo1618 9y ago
> Yes, you can access them; but I don't believe you can link them. I think you can if you use debugfs. I wrote a post here about recovering a running binary after deleting the file on disk: http://lukechampine.com/recoverbin.html http://lukechampine.com/recoverbin.html
- jwilk 9y ago
  Huh, I didn't know debugfs can operate on a mounted filesystem. Sounds incredibly dangerous... debugfs(8) manpage says that ln "does not adjust the inode reference counts". Is there a way to increase that number?
  - adrianmonk 9y ago
    I haven't tried it, but based on the manpage, I would expect this to work: set_inode_field foo links_count 1
    - deleted 9y ago
      [deleted]
  - SpikedCola 9y ago
    Why does it sound dangerous? (Genuinely curious, it looks like it could be a very useful tool in certain situations) I've never used it, but it appears to operate in read-only mode by default[0]: > -w > Specifies that the file system should be opened in read-write mode. Without this option, the file system is opened in read-only mode. [0] https://linux.die.net/man/8/debugfs https://linux.die.net/man/8/debugfs
amelius 9y ago
In POSIX, why can't you link a file to which you have read access, but you're not an owner or have group access? It's a pretty annoying restriction.
- cat199 9y ago
  because you are modifying the file's inode, which you do not have permission to modify.
  - amelius 9y ago
    Ok, but what does it modify besides the refcount?
    - cat199 9y ago
      not sure. but you don't have permission to modify that inode, hence, no permission to link. the model is pretty straightforward. also, being able to 'create' files 'owned' by another user in other locations (by linking them into place) could create quite a few bizarre and undefined corner cases, some of which might have implications for system stability and/or security.
      - jwilk 9y ago
        But... traditionally, Unix systems do allow creating hardlinks of other users' files. And yes, this misfeature is a source of great number of security holes. An option to disable this behavior (/proc/sys/fs/protected_hardlinks) was addded only in Linux 3.6, and then it's still disabled by default.
    - foobiekr 9y ago
      consider what would happen if the file was counted against someone's quota and they rm'd the file but your link was still outstanding.
nine_k 9y ago
I suppose you can read the file if you can intercept an open fd, read it, and write it somewhere. It could possibly be the now vacant previous location.
- jwilk 9y ago
  For me it was (IIRC) a socket, so I couldn't "read it".
hiccuphippo 9y ago
> Yes, you can access them; but I don't believe you can link them. Yes you can. I remember YouTube's flash viewer back in the day would put the downloaded flv video in /tmp and then delete it. I used to check the flash pid, go to /proc/{pid}/fd and see the symlink to the deleted file. Then a cp would give me the actual file.
- nick0garvey 9y ago
  I don't think this is the same as linking the file. You are not creating a new link to an existing file, you are creating a copy of it and creating a link to that. If you modified the old file after the cp, you wouldn't see the changes in the new one.
microtherion 9y ago
On macOS, you might be able to accomplish this with fclonefileat()
tinus_hn 9y ago
On Linux, the linkat(2) function can link up open files using an empty origin path and the AT_EMPTY_PATH flag. That’s not part of POSIX though.

by jwilk 9y ago

dfox 9y ago

You certainly cannot un-unlink file by linking the pseudofile in /proc somewhere, as that would involve cross-filesystem hardlinks. But it is probably possible to write simple kernel module that would allow you to do that through some non-standard interface.

andrewla 9y ago
I don't think the cross-filesystem hardlink is the problem, since the link in proc is a symbolic link. I can do this experimentally by creating a symbolic link in /tmp (a different filesystem) to a file in /home, and then creating a hard link (with ln -L) from the symbolic link to another file in /home, and the result is a valid hardlink to the same inode as the original file. This doesn't work through /proc for an unlinked file, but only because the underlying link call requires a path, not an inode. You can create a hard link out of proc if the file has not been deleted, though, without any cross-filesystem problems.
- dfox 9y ago
  You have to somehow increment inode's reference count and write reference to it into some directory. symlink() does not increase reference count of anything and in fact its target does not have to be meaningful filename at all (although in the practical non-POSIX sense there does not exist any string that is not valid filename). One interesting ab-use of this is that you can use symlink()/readlink() as ad-hoc key-value store with atomicity guarantees (that hold true even on NFS). For example emacs uses exactly this for it's file locking mechanism. IIRC the files in /proc/pid/fd are not true symlinks but something that behaves as both file (you can do same IO operations as on the original FD) and symlink (ie. you can readlink() them and get some string) at once.
  - zokier 9y ago
    man 2 open section about O_TMPFILE seems to strongly imply that you can linkat from /proc/<pid>/fd to concrete file. Not sure if there are some special cases for /proc/self/fd vs /proc/<pid>/fd, but that would seem bit odd. http://man7.org/linux/man-pages/man2/open.2.html http://man7.org/linux/man-pages/man2/open.2.html edit: nevermind, seems like O_TMPFILE is the one that has been special-cased here, from man 2 linkat: > This will generally not work if the file has a link count of zero (files created with O_TMPFILE and without O_EXCL are an exception). http://man7.org/linux/man-pages/man2/linkat.2.html http://man7.org/linux/man-pages/man2/linkat.2.html :(
daurnimator 9y ago
Yes you can. linkat(AT_FDCWD, "/proc/self/fd/N", destdirfd, newname, AT_SYMLINK_FOLLOW); Will do it. This is the longest-available `flink` syscall method. See https://lwn.net/Articles/562488/ https://lwn.net/Articles/562488/ Sadly the AT_EMPTY_PATH change was backed out between 3.11-rc7 and release. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v3.11&id=f0cc6ffb8ce8961db587e5072168cac0cbc25f05 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- jwilk 9y ago
  As pointed out in another comment, this doesn't work when the link count is 0: $ uname -rv 4.15.0-3-amd64 #1 SMP Debian 4.15.17-1 (2018-04-19) $ touch foo $ exec 3<>foo $ rm foo $ ls -l /proc/$$/fd/3 lrwx------ 1 jwilk jwilk 64 Apr 25 10:02 /proc/324/fd/3 -> '/home/jwilk/foo (deleted)' $ strace -e linkat ln -L /proc/$$/fd/3 foo linkat(AT_FDCWD, "/proc/3447/fd/3", AT_FDCWD, "foo", AT_SYMLINK_FOLLOW) = -1 ENOENT (No such file or directory) ln: failed to create hard link 'foo' => '/proc/3447/fd/3': No such file or directory $ sudo strace -e linkat ln -L /proc/$$/fd/3 foo linkat(AT_FDCWD, "/proc/3447/fd/3", AT_FDCWD, "foo", AT_SYMLINK_FOLLOW) = -1 ENOENT (No such file or directory) ln: failed to create hard link 'foo' => '/proc/3447/fd/3': No such file or directory +++ exited with 1 +++
  - deleted 9y ago
    [deleted]
  - daurnimator 9y ago
    Unless you use `O_TMPFILE` without `O_EXCL` to create the file. open("/tmp", O_RDWR|O_TMPFILE, 0666) = 3 linkat(3, "", AT_FDCWD, "/tmp/bar", AT_EMPTY_PATH) = 0

andrewla 9y ago

That's interesting about the access permissions and ownership; I thought that access permissions in POSIX were path-dependent. Some quick experimentation indicates that ownership and access does in fact apply across hard links. There's still some truth to the path-dependent notion, in that you may not be able to access a file through a hard link in a directory that you do not have access to, even if you have access to that same hard link through another path. But if you don't have access to the file itself then you're out of luck. This does make sense from a security perspective, but I thought that the path-dependent checks in the kernel were strong enough to not require inode-associated ACLs. You're right about restoring the file by re-linking to the hard link, but you can access the contents and cp it out of proc at least.

Rapzid 9y ago

I believe you may be able to relink the inode with debugfs, depending on the filesystem.

nemo1618 9y ago

> Yes, you can access them; but I don't believe you can link them. I think you can if you use debugfs. I wrote a post here about recovering a running binary after deleting the file on disk: http://lukechampine.com/recoverbin.html http://lukechampine.com/recoverbin.html

jwilk 9y ago
Huh, I didn't know debugfs can operate on a mounted filesystem. Sounds incredibly dangerous... debugfs(8) manpage says that ln "does not adjust the inode reference counts". Is there a way to increase that number?
- adrianmonk 9y ago
  I haven't tried it, but based on the manpage, I would expect this to work: set_inode_field foo links_count 1
  - deleted 9y ago
    [deleted]
- SpikedCola 9y ago
  Why does it sound dangerous? (Genuinely curious, it looks like it could be a very useful tool in certain situations) I've never used it, but it appears to operate in read-only mode by default[0]: > -w > Specifies that the file system should be opened in read-write mode. Without this option, the file system is opened in read-only mode. [0] https://linux.die.net/man/8/debugfs https://linux.die.net/man/8/debugfs

amelius 9y ago

In POSIX, why can't you link a file to which you have read access, but you're not an owner or have group access? It's a pretty annoying restriction.

cat199 9y ago
because you are modifying the file's inode, which you do not have permission to modify.
- amelius 9y ago
  Ok, but what does it modify besides the refcount?
  - cat199 9y ago
    not sure. but you don't have permission to modify that inode, hence, no permission to link. the model is pretty straightforward. also, being able to 'create' files 'owned' by another user in other locations (by linking them into place) could create quite a few bizarre and undefined corner cases, some of which might have implications for system stability and/or security.
    - jwilk 9y ago
      But... traditionally, Unix systems do allow creating hardlinks of other users' files. And yes, this misfeature is a source of great number of security holes. An option to disable this behavior (/proc/sys/fs/protected_hardlinks) was addded only in Linux 3.6, and then it's still disabled by default.
  - foobiekr 9y ago
    consider what would happen if the file was counted against someone's quota and they rm'd the file but your link was still outstanding.

nine_k 9y ago

I suppose you can read the file if you can intercept an open fd, read it, and write it somewhere. It could possibly be the now vacant previous location.

jwilk 9y ago
For me it was (IIRC) a socket, so I couldn't "read it".

hiccuphippo 9y ago

> Yes, you can access them; but I don't believe you can link them. Yes you can. I remember YouTube's flash viewer back in the day would put the downloaded flv video in /tmp and then delete it. I used to check the flash pid, go to /proc/{pid}/fd and see the symlink to the deleted file. Then a cp would give me the actual file.

nick0garvey 9y ago
I don't think this is the same as linking the file. You are not creating a new link to an existing file, you are creating a copy of it and creating a link to that. If you modified the old file after the cp, you wouldn't see the changes in the new one.

microtherion 9y ago

On macOS, you might be able to accomplish this with fclonefileat()

tinus_hn 9y ago

On Linux, the linkat(2) function can link up open files using an empty origin path and the AT_EMPTY_PATH flag. That’s not part of POSIX though.