Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 May 2001 10:48:47 +0200
From:      Poul-Henning Kamp <phk@critter.freebsd.dk>
To:        Brian Somers <brian@Awfulhak.org>
Cc:        freebsd-arch@FreeBSD.ORG
Subject:   Re: How to handle cloning in a pseudo device. 
Message-ID:  <39755.991212527@critter>
In-Reply-To: Your message of "Wed, 30 May 2001 09:38:26 BST." <200105300838.f4U8cQH31659@hak.lan.Awfulhak.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <200105300838.f4U8cQH31659@hak.lan.Awfulhak.org>, Brian Somers write
s:
>> Hi,
>> 
>> I've been working on making tun clone properly and have come up with 
>> a perplexing problem (well, perplexing to me).
>> 
>> As tun currently works, it calls make_dev() from the clone routine.  
>> If a non-root user does (say) ``touch /dev/tun100'', the clone routine 
>> is called, /dev/tun100 is make_dev()d with root/wheel/600 permissions 
>> and the d_open routine is never called because the user doesn't have 
>> permission to open.

Right.  So far I have refrained from examining modes in the clone
routine and if we can continue to avoid it I would prefer to.

My take on it is that all people can do is create a vnode which
they can "ls -l", and the "CHEAP_CLONE" trick makes sure that
they can't DoS the system.

As for your specific problem, it's pointless to allow regular users
to open a tunnel device because they are not allowed to do the
necessary ifconfig anyway...

>> One way to solve this might be to allocate the softc from the clone 
>> routine, but this means that a rogue user can go into /dev and 
>> potentially run the system out of memory with a quick ``touch'' loop.

Right, that is exactly what you don't want to do.

You need to check for collisions in open, nomatter what you do,
it will always be possible for races to happen between two
or more processes.

What you should do when people try to acccess /dev/tun is to
create a hitherto unopened unit on the tunnel and mark the
dev_t "CHEAP_CLONE".

If people just do an ls -l /dev/tun they get a random line
and that dev_t will be GC'ed pretty quickly.

If they open /dev/tun they get a device and the tunopen allocates
a softc and the dev_t stays.  When you close, remove the softc
and the dev_t should be reclaimed again.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39755.991212527>