Sergiu Ivanov wrote: > Hello, > > On Fri, Dec 25, 2009 at 05:09:40PM +0800, Da Zheng wrote: >> Sergiu Ivanov wrote: >>> - master_device = file_name_lookup (arg, 0, 0); >>> + master_device = file_name_lookup (arg, O_READ | O_WRITE, 0); >> What happens if .MASTER file is read-only? Certainly, >> file_name_lookup in devnode fails. But the questions is: can .MASTER >> node be read-only? > > That's a good point. Consider the following situation: user A sets up > eth-multiplexer on ~A/veth/ and allows only themselves to write into > ~A/veth/ . If user B tries to use ~A/veth/.MASTER via a devnode, B > will get a ``Permission denied'' error. (I've just checked it: A was > root and B was me). > > The question is, however, how critical this restriction is. If, for > example, root sets up a multiplexer for public use, they may also > allow read-write access to its virtual devices. (I've just allowed > 777 access to ~root/veth and my normal user could setup devnode > instances working with .MASTER.) Also, I wonder whether read-only > network devices make sense. (Here I may be lacking information, which > makes me have such an opinion.) read-only network devices allow users to get packets but not write packets. maybe it makes sense.
Maybe devnode can detect the access right of .MASTER first before it calls file_name_lookup(). So if the user doesn't have write access to .MASTER, it just makes its own node read-only. If the user want to change the access right of the devnode node and want to have write access, he just fails. I don't know if it sounds reasonable. just my thought. Zheng Da
