Re: [PATCH] Devnode: Fix the pseudo-master device port opening flags.

[Da Zheng]

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