Messages in this thread | | | Date | Mon, 9 Mar 1998 19:29:47 -0500 (EST) | From | "Albert D. Cahalan" <> | Subject | Re: Idea: flink() and anon_open() |
| |
Malcolm Beattie writes: > Albert D. Cahalan writes:
>>> I'd like to suggest two new system calls. They are logical extensions >>> of the existing filesystem features, and they make it possible to do >>> all sorts of interesting things. I particularly want them because I'm >>> writing a program that will be used to install system-critical files >>> (libc), and there are some race conditions that they would eliminate. >>> >>> First is flink(fd, path). This is exactly like link() except that it >>> takes a file descriptor instead of an existing pathname. This allows >>> you to reattach a file that's been deleted but still open, or name a >>> file whose descriptor was passed to you. >> >> I think flink() is good. > > SysV calls this fattach() where fd is a STREAMS file descriptor > (usually a STREAMS pipe). For general file descriptors, it has > security implications. For example, you mustn't let it be legal > for a process to get a read-only file descriptor and then link > it into the file system because then it could change the file's > permissions to read-write.
How is that worse than fchmod() on the file descriptor? If you own the inode, you can change the permission AFAIK. If you don't own the inode, getting a filename won't help you.
According to the Digital Unix man page, there is some odd behavior with the UID (why?), but it also says: Note that although the attributes of the attached file may change (see the chmod() reference page), the underlying object's attributes will not change accordingly.
Of course, creating a link to something you don't own is a great way to abuse the quota system. Just like chown(), it should not be allowed. (at the very least we could require write access to the object itself!)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |