Date: Wed, 8 Mar 2017 09:23:46 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no> To: James E Keenan <jkeen@verizon.net> Cc: freebsd-questions@freebsd.org Subject: Re: Is there a namei utility in FreeBSD? Message-ID: <alpine.BSF.2.20.1703080915130.533@mail.fig.ol.no> In-Reply-To: <851e783f-f1b9-368b-8dd1-9f99d33dcc38@verizon.net> References: <984464e3-8f4e-d15f-00a8-e341a81d7ab5@verizon.net> <275628a8-8f31-e5b1-9669-62e3ca3f15d6@citrin.ru> <851e783f-f1b9-368b-8dd1-9f99d33dcc38@verizon.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 6 Mar 2017 11:43-0500, James E Keenan wrote: > On 03/06/2017 11:02 AM, Anton Yuzhaninov wrote: > > On 03/06/17 09:12, James E Keenan wrote: > > > In Linux, there is a userland utility 'namei' which enables a user to > > > "follow a pathname until a terminal point is found". Invoking it on, > > > say, a symlink produces output like this: > > > > If you need to find a target of symlink (or symlink chain) you can use > > realpath(1). > > Thanks for mentioning that. However, while the example I gave was that of a > symlink, and while both namei and realpath are good for displaying information > about symlinks, my central question was whether there was an equivalent to > namei in FreeBSD. namei identifies the nature of each component in the > resolved path; realpath does not. I couldn't resist creating my own version of namei(1). This one is BSD two-clause licensed, and I swear I only looked at the two URLs mentioned in the comments and the many man pages of FreeBSD. http://ximalas.info/~trond/namei/c/namei.c The code is a mess and I don't know if the output matches the original beyond what was presented in this thread. Bugs are probably in abundance, and the -v flag isn't implemented yet. The code does work to some extent: $ namei /etc/rc.d/local_unbound f: = /etc/rc.d/local_unbound d / d etc d rc.d - local_unbound $ namei /sys/amd64/conf/GENERIC f: = /sys/amd64/conf/GENERIC d / l sys -> usr/src/sys d usr d src d sys d amd64 d conf - GENERIC $ namei -l /sys/i386/conf/GENERIC f: = /sys/i386/conf/GENERIC drwxr-xr-x root wheel / lrwxr-xr-x root wheel sys -> usr/src/sys drwxr-xr-x root wheel usr drwxr-xr-x root wheel src drwxr-xr-x root wheel sys drwxr-xr-x root wheel i386 drwxr-xr-x root wheel conf -rw-r--r-- root wheel GENERIC Happy hacking. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-questions@freebsd.org Wed Mar 8 08:59:15 2017 Return-Path: <owner-freebsd-questions@freebsd.org> Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81497D01B6B for <freebsd-questions@mailman.ysv.freebsd.org>; Wed, 8 Mar 2017 08:59:15 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ECB851042 for <freebsd-questions@freebsd.org>; Wed, 8 Mar 2017 08:59:14 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id v288wsXo068471; Wed, 8 Mar 2017 19:58:55 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 8 Mar 2017 19:58:54 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Victor Sudakov <vas@mpeks.tomsk.su> cc: Polytropon <freebsd@edvax.de>, Michael Wilcox <michael.wilcox2016@gmail.com>, freebsd-questions@freebsd.org Subject: Re: UFW-Like frontend for IPFW In-Reply-To: <mailman.103.1488888002.35815.freebsd-questions@freebsd.org> Message-ID: <20170307233222.E87835@sola.nimnet.asn.au> References: <mailman.103.1488888002.35815.freebsd-questions@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions <freebsd-questions.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-questions>, <mailto:freebsd-questions-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-questions/>; List-Post: <mailto:freebsd-questions@freebsd.org> List-Help: <mailto:freebsd-questions-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-questions>, <mailto:freebsd-questions-request@freebsd.org?subject=subscribe> X-List-Received-Date: Wed, 08 Mar 2017 08:59:15 -0000 In freebsd-questions Digest, Vol 666, Issue 2, Message: 1 On Mon, 6 Mar 2017 20:43:56 +0700 Victor Sudakov <vas@mpeks.tomsk.su> wrote: > Polytropon wrote: > > On Sun, 5 Mar 2017 17:57:02 +0530, Michael Wilcox wrote: > > > I was wondering if there is any frontend for IPFW. > > > > > > Does anyone have one or must I use it directly? > > > > If I see the analogy correctly, a "UFW-like frontend" already > > is "included" with ipfw, i. e., ipfw works at a comparable > > level. If you compare the ufw commands with the ipfw commands, > > they are quite similar, so you'd use ipfw directly in the same > > manner as you use ufw to interact with iptables. > > > > As an equation: > > > > ufw ipfw > > ---------- = ------ > > iptables ipfw > > > > More or less... ;-) Polytropon: I wish I'd had ufw - or better, ipfw+dummynet for linux - back when I admin'd a couple of debian boxes. iptables is REALLY gnarly without some sort of higher level administration tool, as is tc compared to dummynet. From skimming one ubuntu description, your analogy's good. > There is one thing that a higher level macro language on top of ipfw > would be nice to have for. ipfw rules are very much like an assembly language, and 'assemble' to precisely executable opcodes in a well-defined virtual machine. pf feels (to me) more like 'higher level' coding, which seems to suit many people better .. but I'm an old assembler kind of guy, from S/370 onwards :) > Several times I have tried to emulate Cisco PIX/ASA logic with ipfw. > I just want to have e.g. 3 interfaces: inside, outside, dmz with > security levels of 100, 0, 50 respectively. Traffic can flow from the > interface with a higher security level to the interface with a lower > security level, and return traffic is permitted too. > > Every time I have tried to express this with ipfw rules, I failed > miserably, though superficially it looks simple (with keep-state). That's quite doable, but I wouldn't use numeric levels like that, and I'd use static rules first to limit access between inside, outside and dmz, adding dynamic (stateful) rules after those constraints are met. Just roughly, as a partial sketch, and assuming all at layer 3 (ip): check-state // pass established dynamic flows # can only check both interfaces on 'out' packets, leaving ipfw deny tcp from any to any out recv $dmz_if xmit $inside_if setup deny udp from any to any out recv $dmz_if xmit $inside_if # if dmz provides service/s to outside, skip over these for them # those can be allowed/denied on 'in' pass, using dest address/es. deny tcp from any to any out recv $outside_iface setup deny udp from any to any out recv $outside_iface # skip this for any static (setup then established) services below deny all from any to any established # best use static rules for icmp, see rc.firewall 'workstation' # then (or earlier, if you prefer) separate flows for inside|dmz # then allow services on inside and dmz, perhaps using static rules # then allow access from inside|dmz to dmz|outside statefully. > Has anyone done this? More or less :) My firewalls are mostly static rules, but stateful rules in this instance are likely simpler. Don't be too entranced by statefulness; there are cases (icmp, sometimes DNS, ssh perhaps) where static rules make more sense, and don't suffer from timeouts etc. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1703080915130.533>