From owner-freebsd-arch Wed May 30 1:49: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id CFC7937B422 for ; Wed, 30 May 2001 01:48:56 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter (localhost [127.0.0.1]) by critter.freebsd.dk (8.11.3/8.11.3) with ESMTP id f4U8mlf39757; Wed, 30 May 2001 10:48:47 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Brian Somers Cc: freebsd-arch@FreeBSD.ORG Subject: Re: How to handle cloning in a pseudo device. In-Reply-To: Your message of "Wed, 30 May 2001 09:38:26 BST." <200105300838.f4U8cQH31659@hak.lan.Awfulhak.org> Date: Wed, 30 May 2001 10:48:47 +0200 Message-ID: <39755.991212527@critter> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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