From owner-freebsd-fs Mon Apr 28 20:21:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA20106 for fs-outgoing; Mon, 28 Apr 1997 20:21:14 -0700 (PDT) Received: from mail.webspan.net (mail.webspan.net [206.154.70.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA20101 for ; Mon, 28 Apr 1997 20:21:12 -0700 (PDT) Received: from orion.webspan.net (orion.webspan.net [206.154.70.5]) by mail.webspan.net (WEBSPAN/970116) with ESMTP id XAA11295; Mon, 28 Apr 1997 23:20:53 -0400 (EDT) Received: from orion.webspan.net (localhost [127.0.0.1]) by orion.webspan.net (WEBSPN/970116) with ESMTP id XAA06951; Mon, 28 Apr 1997 23:20:52 -0400 (EDT) To: Michael Hancock cc: David Greenman , Don Lewis , fs@freebsd.org From: "Gary Palmer" Subject: Re: the namei cache... In-reply-to: Your message of "Fri, 25 Apr 1997 12:08:45 +0900." Date: Mon, 28 Apr 1997 23:20:52 -0400 Message-ID: <6949.862284052@orion.webspan.net> Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Hancock wrote in message ID : > However, addressing the performance needs of news servers or large > /var/mail directories might lead to a lot of complications. It's like you > need some kind of dynamic hash table creation capability for each > directory vnode. I don't think this is practical. I don't think any form of non-hashed search will work well with this: root@news:/var/spool/news/misc/jobs/offered> ls | wc -l 20040 or the /var/spool/news/control/cancel directory, which typically has hundreds of thousands of files in it (unless the admin is smart and sets the expire on control.cancel to 0, which will bring it down to a max of about 50,000) Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-fs Tue Apr 29 05:09:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA12824 for fs-outgoing; Tue, 29 Apr 1997 05:09:57 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA12815; Tue, 29 Apr 1997 05:09:53 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id MAA07549; Tue, 29 Apr 1997 12:09:47 GMT Date: Tue, 29 Apr 1997 21:09:47 +0900 (JST) From: Michael Hancock To: Gary Palmer cc: David Greenman , Don Lewis , fs@FreeBSD.org Subject: Re: the namei cache... In-Reply-To: <6949.862284052@orion.webspan.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 28 Apr 1997, Gary Palmer wrote: > > However, addressing the performance needs of news servers or large > > /var/mail directories might lead to a lot of complications. It's like you > > need some kind of dynamic hash table creation capability for each > > directory vnode. I don't think this is practical. > > I don't think any form of non-hashed search will work well with this: > > root@news:/var/spool/news/misc/jobs/offered> ls | wc -l > 20040 > > or the /var/spool/news/control/cancel directory, which typically has > hundreds of thousands of files in it (unless the admin is smart and > sets the expire on control.cancel to 0, which will bring it down to a > max of about 50,000) Poul's analysis regarding stale entries seems to make sense though, there would be an increase in the hit rate if we could efficiently move stale entries to the head of the LRU list or lists. It'd be nice to be able to keep the hash around while solving this problem too though. I'm going to try the Poul's patches in a week or so. I just doing WorldStone on RELENG_2_2, it's not incredibly scientific but it's a nightly cron job anyway and RELENG_2_2 isn't changing very much so you can get somewhat of a controlled environment. Regards, Mike Hancock From owner-freebsd-fs Tue Apr 29 06:33:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA16400 for fs-outgoing; Tue, 29 Apr 1997 06:33:34 -0700 (PDT) Received: from critter.dk.tfs.com (phk.cybercity.dk [195.8.129.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA16389; Tue, 29 Apr 1997 06:33:11 -0700 (PDT) Received: from critter (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id PAA02114; Tue, 29 Apr 1997 15:32:04 +0200 (CEST) To: Michael Hancock cc: Gary Palmer , David Greenman , Don Lewis , fs@FreeBSD.org From: Poul-Henning Kamp Subject: Re: the namei cache... In-reply-to: Your message of "Tue, 29 Apr 1997 21:09:47 +0900." Date: Tue, 29 Apr 1997 15:32:04 +0200 Message-ID: <2112.862320724@critter> Sender: owner-fs@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In message , Micha el Hancock writes: >On Mon, 28 Apr 1997, Gary Palmer wrote: > >> > However, addressing the performance needs of news servers or large >> > /var/mail directories might lead to a lot of complications. It's like you >> > need some kind of dynamic hash table creation capability for each >> > directory vnode. I don't think this is practical. >> >> I don't think any form of non-hashed search will work well with this: >> >> root@news:/var/spool/news/misc/jobs/offered> ls | wc -l >> 20040 Well, the question is how many of them are in the namecache at one time. Few as far as I can tell. It may actually make sense for news servers to only cache directories in the name cache... >Poul's analysis regarding stale entries seems to make sense though, there >would be an increase in the hit rate if we could efficiently move stale >entries to the head of the LRU list or lists. It'd be nice to be able to >keep the hash around while solving this problem too though. There's only one problem, it reduces the max length of names in the cache by another 8 bytes :-( >I'm going to try the Poul's patches in a week or so. I just doing >WorldStone on RELENG_2_2, it's not incredibly scientific but it's a >nightly cron job anyway and RELENG_2_2 isn't changing very much so you can >get somewhat of a controlled environment. WorldStone is not very good for this, or rather, "make depend" is just as good. I'm still playing with various strategies. If anybody are willing to test and measure (with whatever apps you want) it will be much appreciated. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-fs Tue Apr 29 14:54:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA13172 for fs-outgoing; Tue, 29 Apr 1997 14:54:05 -0700 (PDT) Received: from iago.ienet.com (iago.ienet.com [207.78.32.53]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA13167 for ; Tue, 29 Apr 1997 14:54:02 -0700 (PDT) Received: from iago.ienet.com (localhost.ienet.com [127.0.0.1]) by iago.ienet.com (8.8.5/8.8.5) with ESMTP id OAA11773 Tue, 29 Apr 1997 14:53:53 -0700 (PDT) Message-Id: <199704292153.OAA11773@iago.ienet.com> To: freebsd-fs@freebsd.org Cc: terryl@ienet.com From: pius@ienet.com Subject: nfs cache permissions problem? Date: Tue, 29 Apr 1997 14:53:53 -0700 Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've noticed that in a certain case it is possible for a user to obtain access to an NFS-mounted file to which he should not (and does not if the fs were mounted locally) have access to. Here's an example: On host1 (NFS server) (/home -> usr/home): /home/pius>ls -al drwx------ 8 pius wheel 512 Apr 24 15:20 . drwxr-xr-x 8 root wheel 512 Apr 29 12:32 .. -rw-r--r-- 1 pius wheel 227 Nov 14 04:03 .cshrc /home/pius> Only user "pius" should have access to ".cshrc" because the x bit of the directory is off for everyone else. Now host1 exports /usr with -maproot=root -network=A.B.C On host2 (NFS client): (1) su to root mount host1:/usr /mnt (2) user "test" logs in (or is logged in) and tries the following: /home/test>more /mnt/home/pius/.cshrc /mnt/home/pius/.cshrc: Permission denied Ok, that's the expected behaviour. (3) now user "pius" logs in (or is logged in) and does the following: /home/pius>more /mnt/home/pius/.cshrc [ ... ] and he can see the file because user "pius" on the client has the same UID as user "pius" on the server. Ok, everything's still as expected. (4) Now user "test" repeats his last command: /home/test>more /mnt/home/pius/.cshrc [ ... ] and now he can read the file! If I "chmod o-r .cshrc", then user "test" can no longer read the file. I don't know much about NFS, but it appears that the requested file is being cached somewhere, and when it's requested again by another user, the path is not checked again to see that the user has execute permission for every part of the path. Only the permissions on the file itself are checked. By the way, I'm running the following machines: The machine running the NFS server is FreeBSD 2.1.7 (cvsupped and the world last made on 3/20/97) The machine running the NFS client is a pre-Lite2 FreeBSD 3.0 (cvsupped with date=97.02.10.00.00.00) But I can reproduce the same problem with the client on the 2.1.7 machine and the server on the 3.0 machine, with the client on the 2.1.7 machine and the server on a 2.1.5 machine, etc. I've seen a series of recent NFS-related commits to the 3.0 and 2.2 branches, but they seemed unrelated to this permissions problem. Is this something other people can reproduce? Is this just one of the expected hazards one is exposed to when using NFS (with -maproot=root)? Regards, Pius From owner-freebsd-fs Wed Apr 30 00:33:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA11785 for fs-outgoing; Wed, 30 Apr 1997 00:33:35 -0700 (PDT) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA11780 for ; Wed, 30 Apr 1997 00:33:32 -0700 (PDT) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.5/8.8.5) with SMTP id IAA03216; Wed, 30 Apr 1997 08:33:04 +0100 (BST) Date: Wed, 30 Apr 1997 08:33:04 +0100 (BST) From: Doug Rabson To: pius@ienet.com cc: freebsd-fs@FreeBSD.ORG, terryl@ienet.com Subject: Re: nfs cache permissions problem? In-Reply-To: <199704292153.OAA11773@iago.ienet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 29 Apr 1997 pius@ienet.com wrote: > > I've noticed that in a certain case it is possible for a user > to obtain access to an NFS-mounted file to which he should not > (and does not if the fs were mounted locally) have access to. > > [snip] > > I don't know much about NFS, but it appears that the requested file is being > cached somewhere, and when it's requested again by another user, the path > is not checked again to see that the user has execute permission for every > part of the path. Only the permissions on the file itself are checked. I know about this problem and there is an open PR for it. I don't know what the right fix for it is though. I can't do an ACCESS rpc for every cache read (apart from the performance, NFSv2 doesn't have an ACCESS rpc). The best I have come up with so far is to somehow associate a cred with each buf in the cache and only allow accesses which are allowed by the cred. Failures will invalidate the buf and attempt the READ rpc, allowing the server to do the check. > Is this just one of the expected hazards one is exposed to > when using NFS (with -maproot=root)? Afraid so. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-fs Wed Apr 30 14:52:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA20024 for fs-outgoing; Wed, 30 Apr 1997 14:52:10 -0700 (PDT) Received: from iago.ienet.com (iago.ienet.com [207.78.32.53]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA20014 for ; Wed, 30 Apr 1997 14:52:07 -0700 (PDT) Received: from iago.ienet.com (localhost.ienet.com [127.0.0.1]) by iago.ienet.com (8.8.5/8.8.5) with ESMTP id OAA04610 Wed, 30 Apr 1997 14:51:53 -0700 (PDT) Message-Id: <199704302151.OAA04610@iago.ienet.com> From: pius@ienet.com To: Doug Rabson Cc: freebsd-fs@FreeBSD.ORG, terryl@ienet.com Subject: Re: nfs cache permissions problem? Date: Wed, 30 Apr 1997 14:51:53 -0700 Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 30 Apr 1997, dfr@nlsystems.com wrote: > I know about this problem and there is an open PR for it. I don't know > what the right fix for it is though. I can't do an ACCESS rpc for every > cache read (apart from the performance, NFSv2 doesn't have an ACCESS rpc). > The best I have come up with so far is to somehow associate a cred with > each buf in the cache and only allow accesses which are allowed by the > cred. Failures will invalidate the buf and attempt the READ rpc, allowing > the server to do the check. Oops, sorry, I should have checked the PRs first. So the fix provided by the originator of kern/2635 would significantly affect performance? Or perhaps it has other problems? Does the NFSv3 implementation fix this? How do other NFS implementations handle this case (e.g. OpenBSD, NetBSD, Linux, Solaris)? Anyways, thanks very much for your help, Pius From owner-freebsd-fs Wed Apr 30 21:56:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA09108 for fs-outgoing; Wed, 30 Apr 1997 21:56:02 -0700 (PDT) Received: from mail.calweb.com (mail.calweb.com [208.131.56.11]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA09085 for ; Wed, 30 Apr 1997 21:55:59 -0700 (PDT) Received: by mail.calweb.com (8.8.5/8.8.5) with ESMTP id VAA24900 for ; Wed, 30 Apr 1997 21:55:51 -0700 (PDT) X-SMTP: hello web1.calweb.com from cslye@calweb.com server cslye@web1.calweb.com ip 208.131.56.51 Received: (from cslye@localhost) by web1.calweb.com (8.8.5/8.8.5) id VAA20999 for freebsd-fs@freebsd.org; Wed, 30 Apr 1997 21:55:57 -0700 (PDT) Message-Id: <199705010455.VAA20999@web1.calweb.com> Subject: crashing system To: freebsd-fs@freebsd.org Date: Wed, 30 Apr 1997 21:55:57 -3100 (PDT) From: "Cameron Slye" X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Anyone seen errors like the following ? I have vmcore files if anyone can tell me what to look for to help... It seems everytime the system crashes this is the panic.. Any ideas ? dev = 0x2040c, block = 32392, fs = /news/spool panic: blkfree: freeing free block syncing disks... 144 144 140 132 119 109 100 87 68 52 32 5 5 5 5 5 5 5 5 5 giving up --- WARNING: / was not properly dismounted. dev = 0x2040c, block = 28264, fs = /news/spool panic: blkfree: freeing free block syncing disks... 375 375 368 352 342 324 302 276 246 211 173 132 85 35 1 1 1 1 1 1 giving up From owner-freebsd-fs Thu May 1 05:08:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA20505 for fs-outgoing; Thu, 1 May 1997 05:08:47 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA20478 for ; Thu, 1 May 1997 05:08:44 -0700 (PDT) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by who.cdrom.com (8.8.5/8.6.11) with ESMTP id AAA10293 for ; Thu, 1 May 1997 00:47:04 -0700 (PDT) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.5/8.8.5) with SMTP id IAA29252; Thu, 1 May 1997 08:46:25 +0100 (BST) Date: Thu, 1 May 1997 08:46:25 +0100 (BST) From: Doug Rabson To: pius@ienet.com cc: freebsd-fs@freebsd.org, terryl@ienet.com Subject: Re: nfs cache permissions problem? In-Reply-To: <199704302151.OAA04610@iago.ienet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 30 Apr 1997 pius@ienet.com wrote: > > On Wed, 30 Apr 1997, dfr@nlsystems.com wrote: > > I know about this problem and there is an open PR for it. I don't know > > what the right fix for it is though. I can't do an ACCESS rpc for every > > cache read (apart from the performance, NFSv2 doesn't have an ACCESS rpc). > > The best I have come up with so far is to somehow associate a cred with > > each buf in the cache and only allow accesses which are allowed by the > > cred. Failures will invalidate the buf and attempt the READ rpc, allowing > > the server to do the check. > > Oops, sorry, I should have checked the PRs first. > > So the fix provided by the originator of kern/2635 would significantly > affect performance? Or perhaps it has other problems? The problem in 2635 is less severe and the fix is probably OK. The nasty one is accessing normal file data from read/write. I don't want to add an extra rpc to that case if I don't have to. > > Does the NFSv3 implementation fix this? How do other NFS implementations > handle this case (e.g. OpenBSD, NetBSD, Linux, Solaris)? I haven't looked yet. I would expect most BSDs to have the same behaviour as FreeBSD since the NFS code has a common ancestor. > Anyways, thanks very much for your help, You're welcome. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 From owner-freebsd-fs Fri May 2 13:23:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA20912 for fs-outgoing; Fri, 2 May 1997 13:23:40 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA20874 for ; Fri, 2 May 1997 13:23:27 -0700 (PDT) Received: from dash.isi.edu by darkstar.isi.edu (5.65c/5.61+local-25) id ; Fri, 2 May 1997 13:23:10 -0700 Received: from dash.isi.edu (localhost.isi.edu [127.0.0.1]) by dash.isi.edu (8.8.5/8.8.4) with ESMTP id NAA04776; Fri, 2 May 1997 13:23:07 -0700 Message-Id: <199705022023.NAA04776@dash.isi.edu> X-Url: To: fs@freebsd.org Cc: Michael Hancock Subject: Re: NFS bypass op and the utok layer In-Reply-To: Date: Fri, 02 May 1997 13:23:04 -0700 From: John Heidemann Sender: owner-fs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 08 Apr 1997 14:22:39 +0900, Michael Hancock wrote: >On Mon, 7 Apr 1997, John Heidemann wrote: >> >> [There was a bunch of UCLA stackable filing code that didn't go >> into 4.4BSD.] > >I'd like to have a look. Are you volunteering or are you looking for >volunteers? After some e-mail discussions with Michael Hancock I've put a copy of all of the freely available code from my SunOS implementation of stacking up on my web page at . All propriatry bits of code have been removed so this isn't a running system but it may be interesting for study. I am not currently able to contribute to adding this code to FreeBSD (or other OSes), but I am happy to answer questions about the code and I would like to hear from you if you're interested in experimenting with it. -John Heidemann From owner-freebsd-fs Fri May 2 23:02:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA14397 for fs-outgoing; Fri, 2 May 1997 23:02:33 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA14389 for ; Fri, 2 May 1997 23:02:30 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id GAA28929; Sat, 3 May 1997 06:02:20 GMT Date: Sat, 3 May 1997 15:02:20 +0900 (JST) From: Michael Hancock To: John Heidemann cc: fs@FreeBSD.ORG Subject: Re: NFS bypass op and the utok layer In-Reply-To: <199705022023.NAA04776@dash.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 2 May 1997, John Heidemann wrote: > After some e-mail discussions with Michael Hancock I've put a copy of > all of the freely available code from my SunOS implementation of > stacking up on my web page at > . All > propriatry bits of code have been removed so this isn't a running > system but it may be interesting for study. > > I am not currently able to contribute to adding this code to FreeBSD > (or other OSes), but I am happy to answer questions about the code and > I would like to hear from you if you're interested in experimenting > with it. I'm looking into what it would take to do a custom ktou layer to get something more symantic free than NFS. I will then start working on porting INTGEN. Regards, Mike