>>> 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