Linux-kernel mailing list archive 1998-10,: Re: Idea: flink() and anon_open()

# Re: Idea: flink() and anon_open()

Albert D. Cahalan (acahalan@cs.uml.edu)
Mon, 9 Mar 1998 19:29:47 -0500 (EST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Jim Noe: "Re: 2.1.89 doesn't compile"
- Previous message: Jordan Mendelson: "Zombied nfsoid processes?"
- Maybe in reply to: Zack Weinberg: "Idea: flink() and anon_open()"
- Next in thread: Jeremy Fitzhardinge: "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

- Next message: Jim Noe: "Re: 2.1.89 doesn't compile"
- Previous message: Jordan Mendelson: "Zombied nfsoid processes?"
- Maybe in reply to: Zack Weinberg: "Idea: flink() and anon_open()"
- Next in thread: Jeremy Fitzhardinge: "Re: Idea: flink() and anon_open()"