From owner-freebsd-fs Sun Jul 22 2:33:49 2001 Delivered-To: freebsd-fs@freebsd.org Received: from elm.phenome.org (elm.phenome.org [194.153.169.3]) by hub.freebsd.org (Postfix) with ESMTP id 7B4F537B403; Sun, 22 Jul 2001 02:33:45 -0700 (PDT) (envelope-from joshua@roughtrade.net) Received: from localhost (joshua@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6M9XiCC020292; Sun, 22 Jul 2001 10:33:44 +0100 Date: Sun, 22 Jul 2001 10:33:44 +0100 (BST) From: Joshua Goodall X-X-Sender: To: , Subject: flags on symlinks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Is there a particular reason why there's no capability for setting flags on symlinks? the chflags syscall uses namei with FOLLOW, and changing this to NOFOLLOW allows chflags(2) to Do What I Want (i.e. SF_IMMUTABLE on a VLNK) is there a filesystem train crash awaiting me for doing this, or am I in the clear? I realise it changes the semantics of chflags(1) so an alternative syscall or a follow/nofollow boolean addition to struct chflags_args is better than this hack. regards joshua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jul 22 5:27:21 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 688D737B407; Sun, 22 Jul 2001 05:27:16 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA01485; Sun, 22 Jul 2001 22:27:09 +1000 Date: Sun, 22 Jul 2001 22:23:58 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Joshua Goodall Cc: freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 22 Jul 2001, Joshua Goodall wrote: > Is there a particular reason why there's no capability for setting flags > on symlinks? the chflags syscall uses namei with FOLLOW, and changing this > to NOFOLLOW allows chflags(2) to Do What I Want (i.e. SF_IMMUTABLE on a > VLNK) > > is there a filesystem train crash awaiting me for doing this, or am I in > the clear? I realise it changes the semantics of chflags(1) so an > alternative syscall or a follow/nofollow boolean addition to struct > chflags_args is better than this hack. There should be a separate lchflags syscall for this. Obtain it from NetBSD. Several utilities need to be updated to handle flags on symlinks. I'm not sure if NetBSD has implemented this. The hack is probably fairly safe. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jul 22 12:32:24 2001 Delivered-To: freebsd-fs@freebsd.org Received: from peorth.iteration.net (peorth.iteration.net [208.190.180.178]) by hub.freebsd.org (Postfix) with ESMTP id 011E837B405 for ; Sun, 22 Jul 2001 12:32:22 -0700 (PDT) (envelope-from keichii@iteration.net) Received: by peorth.iteration.net (Postfix, from userid 1001) id 28E0959227; Sun, 22 Jul 2001 14:32:21 -0500 (CDT) Date: Sun, 22 Jul 2001 14:32:21 -0500 From: "Michael C . Wu" To: Doug Rabson Cc: Sri Ramkrishna , Alfred Perlstein , Jason Francis , freebsd-fs@FreeBSD.ORG Subject: Re: Porting a new filesystem to FreeBSD Message-ID: <20010722143220.A7100@peorth.iteration.net> Reply-To: "Michael C . Wu" References: <20010716134550.B16516@ichips.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dfr@nlsystems.com on Mon, Jul 16, 2001 at 09:53:47PM +0100 X-PGP-Fingerprint: 5025 F691 F943 8128 48A8 5025 77CE 29C5 8FA1 2E20 X-PGP-Key-ID: 0x8FA12E20 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Jul 16, 2001 at 09:53:47PM +0100, Doug Rabson scribbled: > On Mon, 16 Jul 2001, Sri Ramkrishna wrote: > > It's like wheat germ stuff that are popular in the south. It's somehwat > > like oats. They usually have it with a lot of butter or some jelly. > > It's mostly tasteless. > > Sounds a lot like porridge :-(. In London, go have rice porridge (sometimes called rice soup) :) in Cantonese restaurants in Chinatown. A dimsum place should have it. Ask for a rice porridge with beef and a raw egg in it. The soup is hot, so the raw egg is cooked when you stir the soup, and the soup is hence cooled down to a nice temperature. Try it before you really decide to hate porridge. :) > > To keep this on topic though, I remember some talk about journalling > > filesystems and getting that. Hopefully we'll have one one of these > > days. With disks getting larger and larger (EMC has 181G drives) it's > > getting harder not to go with a journalling type of filesystem. In > > any case, it's just a off hand comment. We'll get there I'm sure. > > Actually, back on topic, I think that FFS+softupdatess+background fsck > gives virtually all the benefits of journalled filesystems. We may need to improve FFS a bit and enhance it with some good features like a versioned filesystem, cryptofs with kernel support, AFS-like features of switching data between volumes, failover writes, etc. -- Michael C. Wu +1-512-7757700 keichii@{iteration.net|freebsd.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jul 22 12:46:58 2001 Delivered-To: freebsd-fs@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 75DF337B401; Sun, 22 Jul 2001 12:46:53 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.247.136.127.Dial1.SanJose1.Level3.net [209.247.136.127]) by hawk.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id MAA10284; Sun, 22 Jul 2001 12:46:29 -0700 (PDT) Message-ID: <3B5B2DBB.16B607E2@mindspring.com> Date: Sun, 22 Jul 2001 12:47:07 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Joshua Goodall , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bruce Evans wrote: > > Is there a particular reason why there's no capability for setting flags > > on symlinks? the chflags syscall uses namei with FOLLOW, and changing this > > to NOFOLLOW allows chflags(2) to Do What I Want (i.e. SF_IMMUTABLE on a > > VLNK) Flags are associated with inodes, and symlinks do not have inodes in the common case, as they exist solely in the directory entry, unless they are too long. > > is there a filesystem train crash awaiting me for doing this, or am I in > > the clear? I realise it changes the semantics of chflags(1) so an > > alternative syscall or a follow/nofollow boolean addition to struct > > chflags_args is better than this hack. > > There should be a separate lchflags syscall for this. Obtain it from > NetBSD. Several utilities need to be updated to handle flags on symlinks. > I'm not sure if NetBSD has implemented this. Pretty clearly, there should _NOT_ be a seperate system call; the damn thing should just work. Adding a seperate system call means theaching everything that deals with flags about it (ls, chflags, every FS supporing symlinks, etc.). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jul 22 13: 3:29 2001 Delivered-To: freebsd-fs@freebsd.org Received: from wellington.cnchost.com (wellington.concentric.net [207.155.252.14]) by hub.freebsd.org (Postfix) with ESMTP id F238237B401; Sun, 22 Jul 2001 13:03:25 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by wellington.cnchost.com id QAA21807; Sun, 22 Jul 2001 16:03:14 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200107222003.QAA21807@wellington.cnchost.com> To: tlambert2@mindspring.com Cc: Bruce Evans , Joshua Goodall , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks In-reply-to: Your message of "Sun, 22 Jul 2001 12:47:07 PDT." <3B5B2DBB.16B607E2@mindspring.com> Date: Sun, 22 Jul 2001 13:03:14 -0700 From: Bakul Shah Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Flags are associated with inodes, and symlinks do not have > inodes in the common case, as they exist solely in the > directory entry, unless they are too long. $ mkdir foo; cd foo; date > x; ln -s x y; ls -lai total 3 261248 drwxr-xr-x 2 bakul bakul 512 Jul 22 12:58 . 261211 drwxr-xr-x 3 bakul bakul 512 Jul 22 12:58 .. 261283 -rw-r--r-- 1 bakul bakul 29 Jul 22 12:58 x 261296 lrwxr-xr-x 1 bakul bakul 1 Jul 22 12:58 y -> x $ cd ..; rm -rf foo > Pretty clearly, there should _NOT_ be a seperate system call; There needs to be. -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jul 22 14:10:22 2001 Delivered-To: freebsd-fs@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id C0EBC37B405; Sun, 22 Jul 2001 14:10:16 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.247.136.127.Dial1.SanJose1.Level3.net [209.247.136.127]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id OAA11771; Sun, 22 Jul 2001 14:10:04 -0700 (PDT) Message-ID: <3B5B4151.C435FF05@mindspring.com> Date: Sun, 22 Jul 2001 14:10:41 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bakul Shah Cc: Bruce Evans , Joshua Goodall , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks References: <200107222003.QAA21807@wellington.cnchost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bakul Shah wrote: > > Flags are associated with inodes, and symlinks do not have > > inodes in the common case, as they exist solely in the > > directory entry, unless they are too long. > > $ mkdir foo; cd foo; date > x; ln -s x y; ls -lai > total 3 > 261248 drwxr-xr-x 2 bakul bakul 512 Jul 22 12:58 . > 261211 drwxr-xr-x 3 bakul bakul 512 Jul 22 12:58 .. > 261283 -rw-r--r-- 1 bakul bakul 29 Jul 22 12:58 x > 261296 lrwxr-xr-x 1 bakul bakul 1 Jul 22 12:58 y -> x > $ cd ..; rm -rf foo > > > Pretty clearly, there should _NOT_ be a seperate system call; > > There needs to be. Why? If the chflags call was defined to always affect its target (and not follow links), then the user space utility could do the stat/readlink itself, and find the correct target, if it wasn't told to not follow links. This is not like "open", where it is an interface everyone knows, loves, and uses. This is an issue for the user space utility; pretty clearly, he wants to apply it to the link itself. In fact, "man chflags", and look at the "-L" argument... I could make a good argument that it should operate on the link itself, if given a "-l" (currently unused) argument. Pushing the link following semantics into the kernel, instead of the C library, was a mistake in the first place; it precludes easy implementation of things like variant symbolic links,which are easily handled in a user space library routine that wraps the actual system call. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jul 22 14:33:56 2001 Delivered-To: freebsd-fs@freebsd.org Received: from assaris.sics.se (dhcp114.iss.kth.se [130.237.7.114]) by hub.freebsd.org (Postfix) with ESMTP id E022037B401; Sun, 22 Jul 2001 14:33:50 -0700 (PDT) (envelope-from assar@assaris.sics.se) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.9.3) id XAA32063; Sun, 22 Jul 2001 23:34:07 +0200 (CEST) (envelope-from assar) To: tlambert2@mindspring.com Cc: Bruce Evans , Joshua Goodall , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks References: <3B5B2DBB.16B607E2@mindspring.com> From: Assar Westerlund Date: 22 Jul 2001 23:34:06 +0200 In-Reply-To: Terry Lambert's message of "Sun, 22 Jul 2001 12:47:07 -0700" Message-ID: <5lhew4ir75.fsf@assaris.sics.se> Lines: 30 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Terry Lambert writes: > Flags are associated with inodes, and symlinks do not have > inodes in the common case, as they exist solely in the > directory entry, unless they are too long. Hu? The contents of the link will be stored in the inode itself rather than in data blocks if it's short enough. > Pretty clearly, there should _NOT_ be a seperate system call; > the damn thing should just work. Adding a seperate system call > means theaching everything that deals with flags about it (ls, > chflags, Of course chflags has to know about it to call chflags or lchflags. But ls should just behave as usual with `-l': datan# ls -lo total 0 -rw-r--r-- 1 root wheel nodump 0 Jul 22 23:31 bar lrwxr-xr-x 1 root wheel schg 3 Jul 22 23:31 foo -> bar datan# ls -loL total 0 -rw-r--r-- 1 root wheel nodump 0 Jul 22 23:31 bar -rw-r--r-- 1 root wheel nodump 0 Jul 22 23:31 foo > every FS supporing symlinks, etc.). Why? /assar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jul 22 14:43:24 2001 Delivered-To: freebsd-fs@freebsd.org Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by hub.freebsd.org (Postfix) with ESMTP id 07FDA37B401; Sun, 22 Jul 2001 14:43:16 -0700 (PDT) (envelope-from hch@ns.caldera.de) Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id f6MLgYL08605; Sun, 22 Jul 2001 23:42:34 +0200 Date: Sun, 22 Jul 2001 23:42:34 +0200 From: Christoph Hellwig To: Terry Lambert Cc: Bruce Evans , Joshua Goodall , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks Message-ID: <20010722234234.A7191@caldera.de> References: <3B5B2DBB.16B607E2@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B5B2DBB.16B607E2@mindspring.com>; from tlambert2@mindspring.com on Sun, Jul 22, 2001 at 12:47:07PM -0700 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Jul 22, 2001 at 12:47:07PM -0700, Terry Lambert wrote: > Bruce Evans wrote: > > > Is there a particular reason why there's no capability for setting flags > > > on symlinks? the chflags syscall uses namei with FOLLOW, and changing this > > > to NOFOLLOW allows chflags(2) to Do What I Want (i.e. SF_IMMUTABLE on a > > > VLNK) > > > Flags are associated with inodes, and symlinks do not have > inodes in the common case, as they exist solely in the > directory entry, unless they are too long. > Erm, Terry? In FFS and derived systems symlinks take an inode. In all other major filesystems I know, too. > Pretty clearly, there should _NOT_ be a seperate system call; > the damn thing should just work. Adding a seperate system call > means theaching everything that deals with flags about it (ls, > chflags, every FS supporing symlinks, etc.). I haven't looked at FreeBSD's namei algorihm in detail, but in theory it could easily do the access checks before calling VOP_READLINK. For the userspace tools: yes the two or three (you forgot at least mtree) the changes need to be done. If you know an idea that implements file flags on symlinks without that change please tell it. Christoph -- Whip me. Beat me. Make me maintain AIX. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jul 22 14:52:35 2001 Delivered-To: freebsd-fs@freebsd.org Received: from elm.phenome.org (elm.phenome.org [194.153.169.3]) by hub.freebsd.org (Postfix) with ESMTP id B68E037B401; Sun, 22 Jul 2001 14:52:29 -0700 (PDT) (envelope-from joshua@roughtrade.net) Received: from localhost (joshua@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6MLq5CC032032; Sun, 22 Jul 2001 22:52:10 +0100 Date: Sun, 22 Jul 2001 22:52:05 +0100 (BST) From: Joshua Goodall X-X-Sender: To: Terry Lambert Cc: Bakul Shah , Bruce Evans , , Subject: Re: flags on symlinks In-Reply-To: <3B5B4151.C435FF05@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 22 Jul 2001, Terry Lambert wrote: > In fact, "man chflags", and look at the "-L" argument... I > could make a good argument that it should operate on the > link itself, if given a "-l" (currently unused) argument. That was my expected result until I read the manpage completely and followed-up through the code. Initial testing and a trawl through the code shows that all ufs symlinks, at least, are first-class vnodes and support flags. NFS returns EOPNOTSUPP, cd9660, union etc returns EROFS. > Pushing the link following semantics into the kernel, instead > of the C library, was a mistake in the first place; it precludes > easy implementation of things like variant symbolic links,which > are easily handled in a user space library routine that wraps > the actual system call. Possibly, but shouldn't we be wary of changing syscall semantics? Especially in code that relates to securelevels. I guess there is general agreement that it is desirable to be able to set schg,sunlink etc on symlinks and fifos. The consistency argument goes like this: Currently exposed as accessor methods to VOP_SETATTR are: chmod(2), fchmod(2), lchmod(2) chown(2), fchown(2), lchown(2) chflags(2), fchflags(2) History records that the semantics for following symlinks in chown & chmod date from 4.4BSD. Since I have been a freebsd admin for some years without giving anything back, I would like to put this together. Joshua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jul 22 15: 1:57 2001 Delivered-To: freebsd-fs@freebsd.org Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by hub.freebsd.org (Postfix) with ESMTP id 87E5737B405; Sun, 22 Jul 2001 15:01:53 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.247.136.127.Dial1.SanJose1.Level3.net [209.247.136.127]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id PAA06925; Sun, 22 Jul 2001 15:01:44 -0700 (PDT) Message-ID: <3B5B4D6D.3F6480A4@mindspring.com> Date: Sun, 22 Jul 2001 15:02:21 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig Cc: Bruce Evans , Joshua Goodall , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks References: <3B5B2DBB.16B607E2@mindspring.com> <20010722234234.A7191@caldera.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Christoph Hellwig wrote: > > Flags are associated with inodes, and symlinks do not have > > inodes in the common case, as they exist solely in the > > directory entry, unless they are too long. > > > > Erm, Terry? > > In FFS and derived systems symlinks take an inode. In all other > major filesystems I know, too. I was thinking of immediate symlinks, which were short-lived in FFS, rather than symlinks in immediate files. Mea culpa. > I haven't looked at FreeBSD's namei algorihm in detail, but in > theory it could easily do the access checks before calling > VOP_READLINK. For the userspace tools: yes the two or three > (you forgot at least mtree) the changes need to be done. > > If you know an idea that implements file flags on symlinks without > that change please tell it. Make chflags not follow links, and follow the links in user space, unless a "-l" is specified, meaning "apply this to the link, instead of following it". -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jul 22 15:10:50 2001 Delivered-To: freebsd-fs@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id AEEDB37B405; Sun, 22 Jul 2001 15:10:39 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.247.136.127.Dial1.SanJose1.Level3.net [209.247.136.127]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id PAA04123; Sun, 22 Jul 2001 15:10:32 -0700 (PDT) Message-ID: <3B5B4F7E.8C48801E@mindspring.com> Date: Sun, 22 Jul 2001 15:11:10 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joshua Goodall Cc: Bakul Shah , Bruce Evans , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Joshua Goodall wrote: > Possibly, but shouldn't we be wary of changing syscall semantics? > Especially in code that relates to securelevels. Pretty much no one uses these calls directly; a grep of the source tree showed only three programs; the default behaviour of the call can be changed safely, if these programs are changed to do the link following in user space, and the man page is updated. > I guess there is general agreement that it is desirable to be able to set > schg,sunlink etc on symlinks and fifos. Probably devices, too, which is a can of worms, particularly with devfs. Already, the fchown/fchmod on sockets and other things which use a non VFS struct fileops fails -- I think this includes FIFO's. > The consistency argument goes like this: > > Currently exposed as accessor methods to VOP_SETATTR are: > chmod(2), fchmod(2), lchmod(2) > chown(2), fchown(2), lchown(2) > chflags(2), fchflags(2) I know the argument for adding more and more system calls; I just don't agree with it. BSDI has already suggested limiting the total number of FreeBSD system calls to something like less than 32 more, total, without going to another block much higher up, and having to have FreeBSD allocate a large, sparse system call array, adding potentially a lot of overhead, depending on future directions with the ABI. In other words: they are getting to be scarce resources. Also note that this will introduce a binary backward compatability problem for the three programs which use the system call, in any case, but in your approach, the programs core dump on an ENOSYS, instead of failing more gracefully. This is sort of like the 5.x mount command, which will cause a 4.x system to panic. Imagine updating, and needing to boot kernel.old. > History records that the semantics for following symlinks in > chown & chmod date from 4.4BSD. Yes. It's a nasty POSIX thing, very much like the nasty POSIX thing of deleting all locks when you have multiple open file instances, and close only one of them. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jul 22 17:23:48 2001 Delivered-To: freebsd-fs@freebsd.org Received: from renown.cnchost.com (renown.concentric.net [207.155.248.7]) by hub.freebsd.org (Postfix) with ESMTP id B6ACD37B405; Sun, 22 Jul 2001 17:23:41 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by renown.cnchost.com id UAA17001; Sun, 22 Jul 2001 20:16:11 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200107230016.UAA17001@renown.cnchost.com> To: tlambert2@mindspring.com Cc: Joshua Goodall , Bruce Evans , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks In-reply-to: Your message of "Sun, 22 Jul 2001 15:11:10 PDT." <3B5B4F7E.8C48801E@mindspring.com> Date: Sun, 22 Jul 2001 17:16:11 -0700 From: Bakul Shah Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > > I guess there is general agreement that it is desirable to be able to set > > schg,sunlink etc on symlinks and fifos. > Probably devices, too, which is a can of worms, particularly > with devfs. > Already, the fchown/fchmod on sockets and other things which > use a non VFS struct fileops fails -- I think this includes > FIFO's. > > The consistency argument goes like this: > > > > Currently exposed as accessor methods to VOP_SETATTR are: > > chmod(2), fchmod(2), lchmod(2) > > chown(2), fchown(2), lchown(2) > > chflags(2), fchflags(2) > > I know the argument for adding more and more system calls; > I just don't agree with it. BSDI has already suggested > limiting the total number of FreeBSD system calls to something > like less than 32 more, total, without going to another block > much higher up, and having to have FreeBSD allocate a large, > sparse system call array, adding potentially a lot of overhead, > depending on future directions with the ABI. Well, I won't mind if {,l}ch{mod,own,flags} etc become library routines. Something like: int chown(const char* path, uid_t owner, gid_t group) { int fd, err; fd = open(path, O_EXCL); if (!fd) return errno; err = fchown(fd, owner, group); close(fd); return err; } But then you must be able to open() a symlink (O_NOFOLLOW flag must not make the open fail). My main argument is for consistent treatment and for `equal rights': if an object has an inode it must have the same rights as any other object also with an inode. devfs is a different kind of beast just like msdosfs so rights of an inode based object are not the same as rights of devfs or msdos fs. Anyway, I argue for either adding a syscall or deleting a few to make a consistent set! Earlier you said: > If the chflags call was defined to always affect its > target (and not follow links), then the user space utility > could do the stat/readlink itself, and find the correct > target, if it wasn't told to not follow links. I don't like running namei twice. Between the stat/readlink and chflags(), things can change. [Digressing a bit...] Ideally I want only the f* version of syscalls, so that you _have_ to `open' an object. Open gives you a handle, a 'capability' to operate on the object. In the past I have argued for *always* passing in a capability even for open(). Then you can throw away even the chdir() call. But then it won't be the unix we know and love and hate! -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jul 22 17:42:52 2001 Delivered-To: freebsd-fs@freebsd.org Received: from ns.caldera.de (ns.caldera.de [212.34.180.1]) by hub.freebsd.org (Postfix) with ESMTP id 2B3CA37B405; Sun, 22 Jul 2001 17:42:46 -0700 (PDT) (envelope-from hch@ns.caldera.de) Received: (from hch@localhost) by ns.caldera.de (8.11.1/8.11.1) id f6N0gKs20365; Mon, 23 Jul 2001 02:42:20 +0200 Date: Mon, 23 Jul 2001 02:42:20 +0200 From: Christoph Hellwig To: Bakul Shah Cc: tlambert2@mindspring.com, Joshua Goodall , Bruce Evans , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks Message-ID: <20010723024220.A19865@caldera.de> References: <3B5B4F7E.8C48801E@mindspring.com> <200107230016.UAA17001@renown.cnchost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107230016.UAA17001@renown.cnchost.com>; from bakul@bitblocks.com on Sun, Jul 22, 2001 at 05:16:11PM -0700 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, Jul 22, 2001 at 05:16:11PM -0700, Bakul Shah wrote: > Well, I won't mind if {,l}ch{mod,own,flags} etc become library > routines. Something like: > > int > chown(const char* path, uid_t owner, gid_t group) { > int fd, err; > > fd = open(path, O_EXCL); > if (!fd) > return errno; > err = fchown(fd, owner, group); > close(fd); > return err; > } The problem is that it uses a file-descriptor, which means it will fail if the maximum number of fds (process-wide or globally) is execeeded. Another problem is that open on devices may give all kinds of side-effects (e.g. enabling interrups, awaking from suspend state, not to mention clone devices) that it is generally considered a bad idea to open for a metadata change. And I think this was discusses as zillion times before :P Christoph -- Whip me. Beat me. Make me maintain AIX. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jul 22 17:47:43 2001 Delivered-To: freebsd-fs@freebsd.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id 8391137B401; Sun, 22 Jul 2001 17:47:35 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.247.136.127.Dial1.SanJose1.Level3.net [209.247.136.127]) by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id RAA14180; Sun, 22 Jul 2001 17:47:28 -0700 (PDT) Message-ID: <3B5B7445.B945A7F5@mindspring.com> Date: Sun, 22 Jul 2001 17:48:05 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bakul Shah Cc: Joshua Goodall , Bruce Evans , freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks References: <200107230016.UAA17001@renown.cnchost.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bakul Shah wrote: > Well, I won't mind if {,l}ch{mod,own,flags} etc become library > routines. Something like: > > int > chown(const char* path, uid_t owner, gid_t group) { > int fd, err; > > fd = open(path, O_EXCL); > if (!fd) > return errno; > err = fchown(fd, owner, group); > close(fd); > return err; > } > > But then you must be able to open() a symlink (O_NOFOLLOW > flag must not make the open fail). Can't be helped: some of the flags will make the write bit fail, if they are set on the link and not on the target; in fact, making the flags work on symlinks is really fraught with peril, I think. It will give a false sense of security, since even if the flags don't permit modification of the link, the link target is up for grabs. Even if it were not, you could always mount an FS over top of the FS containing the link target... and it's still up for grabs, regardless of the current security mode, so long as mounts are permited. > My main argument is for consistent treatment and for `equal > rights': if an object has an inode it must have the same > rights as any other object also with an inode. I normally agree with this -- not to mention symmetry for the interface definitions alone. But the flags stuff is getting out of hand, and really needs to be subsumed in the ACL interface, instead. > devfs is a different kind of beast just like msdosfs so > rights of an inode based object are not the same as rights > of devfs or msdos fs. Anyway, I argue for either adding a > syscall or deleting a few to make a consistent set! Deleting a few is reasonable -- and probably prudent. > > If the chflags call was defined to always affect its > > target (and not follow links), then the user space utility > > could do the stat/readlink itself, and find the correct > > target, if it wasn't told to not follow links. > > I don't like running namei twice. Between the stat/readlink > and chflags(), things can change. You're going to be running it twice, anyway -- and lose your MAXPATHLEN agreement with the kernel, in the bargain, since the link target is potentially expanded as a relative path, and the way it's expanded is _not_ via recursion, it's via expansion into the preexisting pathname buffer. > [Digressing a bit...] > Ideally I want only the f* version of syscalls, so that you > _have_ to `open' an object. Open gives you a handle, a > 'capability' to operate on the object. In the past I have > argued for *always* passing in a capability even for open(). > Then you can throw away even the chdir() call. But then > it won't be the unix we know and love and hate! I'm not that sure; I've always advocated that the POSIX interface belongs in the C library, and if the system itself happens to also have those semantics, OK, but if it does not, well, then OK again. There's a lot of value in having all the normal file calls return stat information, if there is a buffer provided to do the job, since user space file services for PC's and even Macintosh's end up wanting the moral equivalent of stat information on directory iteration, file open, reads, writes, file closes, etc. (see SAMBA or CAP). You can generally get a 30% improvement in file server latency by returning this in the cases it's needed, and halving the number of system calls. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sun Jul 22 20:26:32 2001 Delivered-To: freebsd-fs@freebsd.org Received: from elm.phenome.org (elm.phenome.org [194.153.169.3]) by hub.freebsd.org (Postfix) with ESMTP id 1C77037B401; Sun, 22 Jul 2001 20:26:27 -0700 (PDT) (envelope-from joshua@roughtrade.net) Received: from localhost (joshua@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f6N3QKCC005292; Mon, 23 Jul 2001 04:26:20 +0100 Date: Mon, 23 Jul 2001 04:26:19 +0100 (BST) From: Joshua Goodall X-X-Sender: To: Bakul Shah Cc: , Bruce Evans , , Subject: Re: flags on symlinks In-Reply-To: <200107230016.UAA17001@renown.cnchost.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 22 Jul 2001, Bakul Shah wrote: > Well, I won't mind if {,l}ch{mod,own,flags} etc become library > routines. Something like: I'm not going to take that path, but if you wanted to change the syscall interface, a more radical solution would be creation of a (get|set)attrs call to replace the current [fl]?(chown|chmod|chflags|utimes|stat) set and create libc wrappers. However I am going down the road of a lchflags which is consistent with existing l(chown|chmod|utimes) and also consistent with the NetBSD implementation. I doubt many systems programmers would thank me for radically changing semantics along the way. Regards Joshua To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 23 4:36: 1 2001 Delivered-To: freebsd-fs@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-215.dsl.lsan03.pacbell.net [63.207.60.215]) by hub.freebsd.org (Postfix) with ESMTP id 2D4E937B401 for ; Mon, 23 Jul 2001 04:35:58 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6DA3366CC1; Mon, 23 Jul 2001 04:35:52 -0700 (PDT) Date: Mon, 23 Jul 2001 04:35:50 -0700 From: Kris Kennaway To: fs@FreeBSD.org Subject: [gluk@cvs.openbsd.org: CVS: cvs.openbsd.org: src] Message-ID: <20010723043547.A3951@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Does someone feel like checking whether this is relevant to us? Kris ----- Forwarded message from Grigoriy Orlov ----- Delivered-To: kkenn@localhost.obsecurity.org Date: Sun, 27 May 2001 18:23:03 -0600 (MDT) From: Grigoriy Orlov Subject: CVS: cvs.openbsd.org: src To: source-changes@cvs.openbsd.org Reply-To: Grigoriy Orlov Precedence: bulk Delivered-to: kris@freebsd.org X-Loop: source-changes@openbsd.org CVSROOT: /cvs Module name: src Changes by: gluk@cvs.openbsd.org 2001/05/27 18:23:02 Modified files: sys/kern : vfs_cluster.c=20 Log message: cluster_rbuild() have a race between incore and getblk. incore() returns zero indicating that buffer is not in a cache, but getblk() going to sleep: getblk->getnewbuf->tsleep. When getnewbuf() returns after a sleep, getblk() may find B_DONE buffer in hash and return it. When io operation finishes biodone() calls cluster_callback() which moves pages from one big cluster buffer into several component buffers and calls biodone() for every compone= nt buffer. Since there are a component buffer with B_DONE already set, biodone= () panices: "biodone already". costa@ ok. ----- End forwarded message ----- --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7XAwRWry0BWjoQKURArbJAJ9MrJI5PAehq8ipB/umfM4iiCidtgCfVC07 U5xl7Gly6VBQe+kL7nEnJiI= =EfqE -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 23 5: 7:37 2001 Delivered-To: freebsd-fs@freebsd.org Received: from web13304.mail.yahoo.com (web13304.mail.yahoo.com [216.136.175.40]) by hub.freebsd.org (Postfix) with SMTP id A0AB037B408 for ; Mon, 23 Jul 2001 05:07:30 -0700 (PDT) (envelope-from sumirati@yahoo.de) Message-ID: <20010723120730.53500.qmail@web13304.mail.yahoo.com> Received: from [193.174.9.99] by web13304.mail.yahoo.com via HTTP; Mon, 23 Jul 2001 14:07:30 CEST Date: Mon, 23 Jul 2001 14:07:30 +0200 (CEST) From: =?iso-8859-1?q?m=20p?= Subject: Re: Porting a new filesystem to FreeBSD To: Greg Lehey Cc: jasonf@citynet.net, freebsd-fs@freebsd.org In-Reply-To: <20010718100819.A70499@wantadilla.lemis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org sorry for the format. i configured the web-frontend now. hope the results are better. --- Greg Lehey schrieb: > [Format recovered--see http://www.lemis.com/email/email-format.html] > > Please read this document. Your messages verge on the unreadable, and > it has taken me 5 minutes to tidy up the reply. > > On Tuesday, 17 July 2001 at 12:14:17 +0200, m p wrote: > On Tuesday, 17 July 2001 at 12:25:29 +0200, m p wrote: > > I can't see any differences between these two messages. Was there > one? > there was no difference between them. i hit the send button only once. > > --- Greg Lehey schrieb: > > On Tuesday, 17 July 2001 at 10:22:10 +0200, m p wrote: > >>> 2) What filesystem/booting-process/lvm-stuff is under development > >>> in -current? > >> > >> Vinum root file systems are just a SMOP away. I had it running > >> over a year ago, but didn't have time to make some minor > >> modifications. > > > > In a statement (i don't remember where; a quick google search i > > didn't found it) a road-plan was described. It mentioned a project > > hosted at www.freebsd/~??? (it was three letters i rember). There > > was a new layout for volumes and the boot process described. > > I'm afraid you're going to have to quote these things correctly > yourself. You can't expect other people to search for you. i just thought that someone remembered the mail/document too. > > >>> 4) How do i kernel programming (if needed)? > >> > >> I don't understand this question. > > > > I had never done kernel hacking before. (Perhaps the sentence above > > would read better this way: how do i do porgramming at the kernel > > level "the right way" tm?) And yes, i will buy the book mentioned > > by Kris Kennaway some days ago at freebsd-questions " Design and > > Implementation of the 4.4BSD Operating System". Is there another > > good source about kernel hacking? > > The 4.4BSD book will give you an understanding of the kernel > structure. It won't help with kernel hacking. If you haven't done > any kernel work before, porting a file system is probably overly > ambitious. You should certainly join the FreeBSD-hackers list and > look through the lists at http://www.freebsd.org/projects/ and > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/contrib.html > and see if there's something interesting to work on there. there is something. but i want a project where i can set my own speed. where i can switch from one point to the another. so a "new" project seemed to fit best. > > >>> 5) What _exactly_ is a filesystem? > >> > >> Well, I would think you would understand this already. Or maybe > >> I'm misunderstanding your point. > > > > I don't know much about concepts behind that word. What _exactly_ > > means journaling? How is made sure, that the log-files to replay the > > action are consistent? etc. I heard about filesystems a little > > bit. It is a way to learn more about them. But to know more about > > that will make the work easier. > > Again, perusal of the web pages will help. Try > http://oss.software.ibm.com/jfs/ for a start. ok. another try: IMHO if i had never ported/written a filesystem myself i don't knew the beast exactly. i heard classes at university about filesystems in theory - but that is the easy thing - i think. the pages at ibm will be the start lecture. and the code published by them. > > >>> When these points are clear (worst case i have to do a research on > >>> all 5, best case only on point 1) i will start the project. > >>> > >>> Is there any big step i missed during > >> brainstorming? > >> > >> Well, maybe the magnitude of the project. It's not easy, and even > >> the recently released Linux version of the file system has > >> significant "issues". > > > > As i mentioned: i've got plenty of time the next year working under > > the week somewhere else and living in a motel. No people i knew > > nearby. So coding will prevent me from looking to much tv. :) > > Sounds like an ambitious project. As I said, I can support you, but > you may find it more difficult than you bargained for. thanks a lot. this week i got my computers in the appartment. modem still missing. but i will start to read a little bit of kernel code as "gute-nacht-lektuere". ;) marc __________________________________________________________________ Do You Yahoo!? Gesendet von Yahoo! Mail - http://mail.yahoo.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 23 10:24:49 2001 Delivered-To: freebsd-fs@freebsd.org Received: from 21.232.01.7 (OL154-95.fibertel.com.ar [24.232.95.154]) by hub.freebsd.org (Postfix) with SMTP id 0E0D437B40A for ; Mon, 23 Jul 2001 10:24:29 -0700 (PDT) (envelope-from juan_cruz_roux@hotmail.com) X-Server: hotmail From: Juan Cruz Roux To: Reply-To: juan_cruz_roux1@hotmail.com X-Mailer: MultiMailer (3.1.0) Subject: Estimado Usuario Mime-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message-Id: <20010723172429.0E0D437B40A@hub.freebsd.org> Date: Mon, 23 Jul 2001 10:24:29 -0700 (PDT) Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Filtrar el= agua de bebida incrementa nuestra calidad de= vida.

La mayoria de los malos sabores,= olores y turbidez presente en el agua potable son causados por= la presencia de cloro y materiales orgánicos.

El cloro utilizado muy eficazmente= para potabilizar el agua de bebida, es causal del mal sabor y en= mayor cantidad es perjudicial para la salud.
El material orgánico presente en tanques y cañerias= de agua corrientes (residuos de hojas, insectos, etc.) le= agregan al agua turbidez y mal sabor.

También tenemos la combinación del material= orgánico con el cloro, formando los peligrosos= Trihalometanos (THM), compuesto altamente tóxico.

La forma mas simple y efectiva para remover tanto el cloro como= el material orgánico y los THM es mediante el pasaje del= agua a través de un filtro purificador (*)= con lecho de carbón activado.

(*) CUNO= posee mas de 90 años de experiencia en= purificación y filtración de agua, y provee= filtros de agua a empresas como Mc Donald's en Argentina y en el= mundo.


Si quiere recibir más información sobre este tema= comuníquese al
011- 4555-6050=

o desde el interior sin cargo al=
0800-222-6392

Gracias.


= NeWater= Argentina
Purificación de agua para= empresas y hogares
 Charlone 516 , Buenos Aires, Argentina
= tel: 011-4555-6050(rot.)
 email: newater@movi.com.ar




Si usted= no desea recibir mas información nuestra envíenos= un email con asunto "Borrar". Gracias.

Produced= by La Jolla Advertiding Co., CA, USA
en Argentina 011-15-4947-7618




 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 23 20:25:36 2001 Delivered-To: freebsd-fs@freebsd.org Received: from obsecurity.dyndns.org (adsl-63-207-60-215.dsl.lsan03.pacbell.net [63.207.60.215]) by hub.freebsd.org (Postfix) with ESMTP id 5724E37B403 for ; Mon, 23 Jul 2001 20:25:28 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 9CD8A66B04; Mon, 23 Jul 2001 20:25:27 -0700 (PDT) Date: Mon, 23 Jul 2001 20:25:27 -0700 From: Kris Kennaway To: fs@FreeBSD.org Subject: [viro@math.psu.edu: Locally exploitable races in OpenBSD VFS] Message-ID: <20010723202526.B96630@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7ZAtKRhVyVSsbBD2" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --7ZAtKRhVyVSsbBD2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Has anyone looked at whether these apply to us? Kris ----- Forwarded message from Alexander Viro ----- Delivered-To: kkenn@localhost.obsecurity.org Date: Sat, 02 Jun 2001 19:00:08 -0400 (EDT) From: Alexander Viro Subject: Locally exploitable races in OpenBSD VFS To: BUGTRAQ@securityfocus.com Precedence: bulk Delivered-to: kris@freebsd.org Delivered-to: mailing list bugtraq@securityfocus.com Delivered-to: moderator for bugtraq@securityfocus.com Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm List-Id: List-Post: List-Help: List-Unsubscribe: List-Subscribe: X-Authentication-warning: weyl.math.psu.edu: viro owned process doing -bs [my apologies if it ends up submitted twice] Let's start with the trivial: good old aliasing bugs. Example 1: dup2() vs. close(). Relevant file: kern/kern_descrip.c sys_dup2(p, v, retval) struct proc *p; void *v; register_t *retval; { [snip] if ((u_int)old >=3D fdp->fd_nfiles || fdp->fd_ofiles[old] =3D=3D NU= LL || (u_int)new >=3D p->p_rlimit[RLIMIT_NOFILE].rlim_cur || (u_int)new >=3D maxfiles) return (EBADF); OK, we've checked (among other things) that old is indeed opened. [snip] if (new >=3D fdp->fd_nfiles) { We either expand a descriptor table [snip] } else { Or reuse existing descriptor, closing file if it's opened. (void) fdrelease(p, new); Which is the blocking operation, BTW. } return (finishdup(fdp, old, new, retval)); } [snip] finishdup(fdp, old, new, retval) register struct filedesc *fdp; register int old, new; register_t *retval; { register struct file *fp; fp =3D fdp->fd_ofiles[old]; Got the struct sile of the file we are trying to dup... if (fp->f_count =3D=3D LONG_MAX-2) =2E.. and dereference it. We had checked that it's non-NULL, right? Wrong. Another thread might be sharing our descriptor table (man rfork). IOW, fdp points to shared data structure. So we had done the equivalent of if (global_var) { blocking_call(); if (global_var->f_count) ... } Sloppy? Yes, and way beyond that. We have a nice shiny race between dup2(0,1); and close(0). And it's a wide one. Turning that into full-blown exploit is left as an exercise for readers. Example 2: pipe() vs. close() (kern/sys_pipe.c) sys_opipe(p, v, retval) [snip] error =3D falloc(p, &rf, &fd); if (error) goto free2; [snip] retval[0] =3D fd; error =3D falloc(p, &wf, &fd); if (error) goto free3; [snip] return (0); free3: ffree(rf); fdremove(fdp, retval[0]); free2: [snip] Think what happens if the second allocation fails. It is a blocking call. During that time another thread had a nice possibility to call close(retval[0]); since that value is very easy to predict - it's the first available file descriptor. close() would * remove pointer from fdp[retval[0]] * call ffree() on it. Now, we come back and do _another_ ffree() on the poor beast. Welcome to kernel panic... Code is equivalent to global_var =3D p =3D alloc_foo(); blocking_call(); release_foo(p); global_var =3D NULL; It's not just sloppy. It's obviously broken - obviously for anyone with half of clue. I can easily provide more examples of the same crap and so can anyone who would bother to RTFS the descriptor handling in kern/*. Apparently that had never happened during the last 5 years or so. I'm not talking about the bugs that would require anything nontrivial to find and understand. Just follow the yello^Wpiles of sloppy C and nearly every one will turn out to be exploitable. And no, it's not limited to descriptor handling - same goes for sys_pipe.c, etc. Theo had been informed about that crap. Couple of weeks ago. Finding and fixing these bugs is a simple matter of grep. So far it hadn't been done. I've proposed to help with that, but apparently it got no interest. = =20 Very well, there are other piles of garbage in need of fixing and seeing crappy code in obscure Linux drivers is less disturbing than that in core kernel. Frankly. my respect to Theo went way down. This code had never been read through, let alone audited. And that's the core kernel. Moreover, the same bugs had been fixed in FreeBSD half a year ago. In other words, just keeping an eye on other *BSD trees would be enough to catch them. Same for lurking on freebsd-hackers. Same for watching the Linux tree, where an audit of relevant areas had been done nearly two years ago. Done and discussed on linux-kernel. Sad... #include --=20 "You're one of those condescending Unix computer users!" "Here's a nickel, kid. Get yourself a better computer" - Dilbert. ----- End forwarded message ----- --7ZAtKRhVyVSsbBD2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7XOqmWry0BWjoQKURAut7AJ9ISEf9Pvv78XWl2V/A4AuYnjxAuwCgrgaj cAKVbKl2vn3umIeRNCe6SaI= =V/gp -----END PGP SIGNATURE----- --7ZAtKRhVyVSsbBD2-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 23 20:35:13 2001 Delivered-To: freebsd-fs@freebsd.org Received: from tomts13-srv.bellnexxia.net (tomts13.bellnexxia.net [209.226.175.34]) by hub.freebsd.org (Postfix) with ESMTP id 4B54237B401 for ; Mon, 23 Jul 2001 20:35:08 -0700 (PDT) (envelope-from matt@gsicomp.on.ca) Received: from xena.gsicomp.on.ca ([64.228.155.124]) by tomts13-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010724033507.WUSQ29255.tomts13-srv.bellnexxia.net@xena.gsicomp.on.ca>; Mon, 23 Jul 2001 23:35:07 -0400 Received: from hermes (hermes.gsicomp.on.ca [192.168.0.18]) by xena.gsicomp.on.ca (8.11.1/8.11.1) with SMTP id f6O3WUc88043; Mon, 23 Jul 2001 23:32:30 -0400 (EDT) (envelope-from matt@gsicomp.on.ca) Message-ID: <002b01c113f0$df8e7aa0$1200a8c0@gsicomp.on.ca> From: "Matthew Emmerton" To: "Kris Kennaway" , References: <20010723202526.B96630@xor.obsecurity.org> Subject: Re: [viro@math.psu.edu: Locally exploitable races in OpenBSD VFS] Date: Mon, 23 Jul 2001 23:29:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Has anyone looked at whether these apply to us? > > Kris > > ----- Forwarded message from Alexander Viro ----- > > > > > > [ snip ] > > ... Moreover, the same bugs had been fixed in FreeBSD half a year ago. ... > > Does that answer your question? I took a brief look through the source files mentioned, but am not familiar enough with it to agree or disagree, although it appears significantly different than the OpenBSD code, and would appear to avoid race conditions. -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Mon Jul 23 22:37:15 2001 Delivered-To: freebsd-fs@freebsd.org Received: from sneakerz.org (sneakerz.org [216.33.66.254]) by hub.freebsd.org (Postfix) with ESMTP id 23D1137B403; Mon, 23 Jul 2001 22:37:05 -0700 (PDT) (envelope-from bright@sneakerz.org) Received: by sneakerz.org (Postfix, from userid 1092) id 90E3A5D010; Tue, 24 Jul 2001 00:36:54 -0500 (CDT) Date: Tue, 24 Jul 2001 00:36:54 -0500 From: Alfred Perlstein To: Kris Kennaway Cc: fs@FreeBSD.org, tanimura@freebsd.org Subject: Re: [viro@math.psu.edu: Locally exploitable races in OpenBSD VFS] Message-ID: <20010724003654.B68587@sneakerz.org> References: <20010723202526.B96630@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20010723202526.B96630@xor.obsecurity.org>; from kris@obsecurity.org on Mon, Jul 23, 2001 at 08:25:27PM -0700 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Kris Kennaway [010723 22:25] wrote: > Has anyone looked at whether these apply to us? It's possible, Tanimura and I are working on a patchset dealing with shared filedescriptors and SMP, we'll let keep you updated. > > Kris > > ----- Forwarded message from Alexander Viro ----- > > Delivered-To: kkenn@localhost.obsecurity.org > Date: Sat, 02 Jun 2001 19:00:08 -0400 (EDT) > From: Alexander Viro > Subject: Locally exploitable races in OpenBSD VFS > To: BUGTRAQ@securityfocus.com > Precedence: bulk > Delivered-to: kris@freebsd.org > Delivered-to: mailing list bugtraq@securityfocus.com > Delivered-to: moderator for bugtraq@securityfocus.com > Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm > List-Id: > List-Post: > List-Help: > List-Unsubscribe: > List-Subscribe: > X-Authentication-warning: weyl.math.psu.edu: viro owned process doing -bs > > [my apologies if it ends up submitted twice] > Let's start with the trivial: good old aliasing bugs. > > Example 1: > dup2() vs. close(). Relevant file: kern/kern_descrip.c > > sys_dup2(p, v, retval) > struct proc *p; > void *v; > register_t *retval; > { > [snip] > if ((u_int)old >= fdp->fd_nfiles || fdp->fd_ofiles[old] == NULL || > (u_int)new >= p->p_rlimit[RLIMIT_NOFILE].rlim_cur || > (u_int)new >= maxfiles) > return (EBADF); > OK, we've checked (among other things) that old is indeed opened. > [snip] > if (new >= fdp->fd_nfiles) { > We either expand a descriptor table > [snip] > } else { > Or reuse existing descriptor, closing file if it's opened. > (void) fdrelease(p, new); > Which is the blocking operation, BTW. > } > return (finishdup(fdp, old, new, retval)); > } > [snip] > finishdup(fdp, old, new, retval) > register struct filedesc *fdp; > register int old, new; > register_t *retval; > { > register struct file *fp; > > fp = fdp->fd_ofiles[old]; > Got the struct sile of the file we are trying to dup... > if (fp->f_count == LONG_MAX-2) > ... and dereference it. We had checked that it's non-NULL, right? > > Wrong. Another thread might be sharing our descriptor table (man rfork). > IOW, fdp points to shared data structure. So we had done the equivalent of > > if (global_var) { > blocking_call(); > if (global_var->f_count) > ... > } > > Sloppy? Yes, and way beyond that. We have a nice shiny race between > dup2(0,1); and close(0). And it's a wide one. Turning that into > full-blown exploit is left as an exercise for readers. > > Example 2: > pipe() vs. close() (kern/sys_pipe.c) > > sys_opipe(p, v, retval) > [snip] > error = falloc(p, &rf, &fd); > if (error) > goto free2; > [snip] > retval[0] = fd; > > error = falloc(p, &wf, &fd); > if (error) > goto free3; > [snip] > return (0); > free3: > ffree(rf); > fdremove(fdp, retval[0]); > free2: > [snip] > > Think what happens if the second allocation fails. It is a > blocking call. During that time another thread had a nice possibility > to call close(retval[0]); since that value is very easy to predict - > it's the first available file descriptor. close() would > * remove pointer from fdp[retval[0]] > * call ffree() on it. > Now, we come back and do _another_ ffree() on the poor beast. Welcome to > kernel panic... > > Code is equivalent to > > global_var = p = alloc_foo(); > blocking_call(); > release_foo(p); > global_var = NULL; > > It's not just sloppy. It's obviously broken - obviously for anyone with > half of clue. > > I can easily provide more examples of the same crap and so can anyone > who would bother to RTFS the descriptor handling in kern/*. Apparently > that had never happened during the last 5 years or so. > > I'm not talking about the bugs that would require anything nontrivial to > find and understand. Just follow the yello^Wpiles of sloppy C and nearly > every one will turn out to be exploitable. And no, it's not limited to > descriptor handling - same goes for sys_pipe.c, etc. > > Theo had been informed about that crap. Couple of weeks ago. Finding and > fixing these bugs is a simple matter of grep. So far it hadn't been done. > I've proposed to help with that, but apparently it got no interest. > Very well, there are other piles of garbage in need of fixing and seeing > crappy code in obscure Linux drivers is less disturbing than that in core > kernel. > > Frankly. my respect to Theo went way down. This code had never been read > through, let alone audited. And that's the core kernel. Moreover, the > same bugs had been fixed in FreeBSD half a year ago. In other words, just > keeping an eye on other *BSD trees would be enough to catch them. Same > for lurking on freebsd-hackers. Same for watching the Linux tree, where > an audit of relevant areas had been done nearly two years ago. Done and > discussed on linux-kernel. Sad... > > #include > > -- > "You're one of those condescending Unix computer users!" > "Here's a nickel, kid. Get yourself a better computer" - Dilbert. > > ----- End forwarded message ----- -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Tue Jul 24 9:30:43 2001 Delivered-To: freebsd-fs@freebsd.org Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by hub.freebsd.org (Postfix) with ESMTP id 06B4637B40B for ; Tue, 24 Jul 2001 09:30:29 -0700 (PDT) (envelope-from cattelan@thebarn.com) Received: from thebarn.com ([63.231.179.33]) by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f6OGUQNe056526; Tue, 24 Jul 2001 11:30:27 -0500 (CDT) Message-ID: <3B5DA230.5070406@thebarn.com> Date: Tue, 24 Jul 2001 11:28:32 -0500 From: Russell Cattelan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713 X-Accept-Language: en-us MIME-Version: 1.0 To: m p Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Porting a new filesystem to FreeBSD References: <20010717082210.76404.qmail@web13303.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org If you really are willing to help port a FS to FreeBSD, you could help with the XFS port. :-) It is a bit stalled at the moment as I'm busy doing work that generates income, but I do get a chance to bang on it once in a while ... hopefully I will be able to mount a FS soon. Note to quickly answer one of your questions, yes some modifications will be need to the core kernel code to support pinning, but I suspect is will be very minor due to support for softupdates. Ohh and porting a linux FS to BSD is much more difficult than porting a IRIX FS to BSD, linux has a different IO layering concept than other unix systems. m p wrote: >Hi, > >let it be technical again. > >I wanted to do a little bit more research before >bringing up the idea of porting the GPLed version of >JFS to *BSD. But now is better than else. > >JFS would be a nice thing for >mail/database/http/file-servers. I can not state "that >filesystem is better than this". But a filesystem >developed by a big company to use it with linux - why >do we not port it? > >Things i wanted to research before starting it: >1) Is there anybody doing it and needing help? >2) What filesystem/booting-process/lvm-stuff is under >development in -current? >3) How do i have to modify the kernel to support JFS? >(or modify the linux kernel wrapper) >4) How do i kernel programming (if needed)? >5) What _exactly_ is a filesystem? > >When these points are clear (worst case i have to do a >research on all 5, best case only on point 1) i will >start the project. > >Is there any big step i missed during brainstorming? > >I've got a lot of time left, 300 km from home alone in >a motel. > >Thanks for any hints > >Marc > >__________________________________________________________________ >Do You Yahoo!? >Gesendet von Yahoo! Mail - http://mail.yahoo.de > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-fs" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Fri Jul 27 21:50: 7 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail.cablespeed.com (mail.cablespeed.com [206.112.192.76]) by hub.freebsd.org (Postfix) with ESMTP id 3688A37B403 for ; Fri, 27 Jul 2001 21:50:04 -0700 (PDT) (envelope-from mccrobie@cablespeed.com) Received: from cablespeed.com (c216-45-72-227.md1.cablespeed.com [216.45.72.227]) by mail.cablespeed.com (8.9.3/8.9.3) with ESMTP id VAA19465 for ; Fri, 27 Jul 2001 21:50:03 -0700 Message-ID: <3B624476.92A36689@cablespeed.com> Date: Sat, 28 Jul 2001 00:49:58 -0400 From: Chuck McCrobie X-Mailer: Mozilla 4.72 [en] (X11; I; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-fs@freebsd.org Subject: Softupdates & NFS semantics Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've been looking at the softupdate papers and code implementation in FreeBSD 4.2/4.3 with respect to NFS semantics - specifically for create, remove, etc. I'm not as concerned about writes since NFS v3 allows unstable writes. Here is my question: It seems that with softupdates turned on, the NFS create call, when it returns to the client, has written neither the new inode nor the directory block to disk. Is this correct? If this is correct, doesn't this break the NFS semantics? It would therefore seem that an NFS server must turn off softupdates on its NFS exported file systems. Is this correct? Thank you, Chuck McCrobie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jul 28 4:26: 4 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mydomain.com (t3o102p2.telia.com [194.255.255.2]) by hub.freebsd.org (Postfix) with ESMTP id 92CA837B408; Sat, 28 Jul 2001 04:25:51 -0700 (PDT) (envelope-from world1web@www.com) Date: Sat, 28 Jul 2001 13:25:49 +0100 From: WORLD1-WEB To: WORLD1-WEB@FreeBSD.ORG Subject: INCREDIBLE .. WORLDS NO.1 !! Message-Id: <20010728112551.92CA837B408@hub.freebsd.org> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ladies & Gentlemen, Are you ready to the experience of a lifetime ? As affiliates of the CIL group, we offer you to PLUGIN to the largest SEX-SERVER on the WEB, in order to get more than 3000 MegaBytes of the best and most sensational SEX on the entire Web! Why on earth do you think that thousands of people from 13 countries daily choose to visit 2 particular WebSites ? Very EASY answer! - The largest and most incredible content of LIVE SEX is offered! - State-of-the-art LIVE SHOWS with the wildest and most horny amateurs and pornstars in the world! - Hardcore LIVE SEX that hasnīt crossed your imagination! - Incredible & amazing themes from soft sex to the most bizarre sex! - Beautiful Girls & wild studs from almost every country, allowing you to watch, see & chat with awsome amateurs & pornstars who are blond, who are black, who are Scandinavian, who are Asian, who have BIG tits, who are shaved, who are pregnant who are .... you just name it ! - The best ever made SPY-CAMS, WATCH-CAMS, POOL-CAMS, SHOWER-CAMS, AMATEUR-CAMS ... etc! - Several high quality Interactive Cams & LIVE SEX Chat, where you are in controle ! - Much much more ... too much to mention ! EVERYTHING is offered 100% ANONOMOUSLY & you donīt need to sign-up or have a creditcard ... How simple is that ? PLUGIN now to our MEGA SEX-SERVER through any of the 2 AwardWinning Sites listed below, and get instantly access to more than 3000 MegaBytes of State-of-the-art WebSex! RIGHT HERE AT: http://siam.to/sexywebtv (This Site just has EVERYTHING you can imagine) ... If this Site does not open properly ... please try http://cyberu.to/hotweb Or this one, if you just love true LESBIAN SEX, CHAT and MORE from Sunny Ibiza in Spain: http://siam.to/sexybabestv ... If this Site does not open properly ... please try http://cyberu.to/hotbabes Enjoy your trip to paradise! VERY IMPORTANT HINT: To get DIRECT ACCESS to the webpages in the future, ALLWAYS keep the DIALER on your desktop or elsewhere on your PC ... Its easy, small and 100% harmless. Yours sincerely, WORLD1-WEB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jul 28 8:12:39 2001 Delivered-To: freebsd-fs@freebsd.org Received: from pop3.psconsult.nl (ps226.psconsult.nl [193.67.147.226]) by hub.freebsd.org (Postfix) with ESMTP id DE40737B405; Sat, 28 Jul 2001 08:12:23 -0700 (PDT) (envelope-from paul@pop3.psconsult.nl) Received: (from paul@localhost) by pop3.psconsult.nl (8.9.2/8.9.2) id RAA52812; Sat, 28 Jul 2001 17:12:15 +0200 (CEST) (envelope-from paul) Date: Sat, 28 Jul 2001 17:12:15 +0200 From: Paul Schenkeveld To: Bakul Shah Cc: freebsd-fs@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: flags on symlinks Message-ID: <20010728171214.A52461@psconsult.nl> References: <3B5B4F7E.8C48801E@mindspring.com> <200107230016.UAA17001@renown.cnchost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200107230016.UAA17001@renown.cnchost.com>; from bakul@bitblocks.com on Sun, Jul 22, 2001 at 05:16:11PM -0700 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Guys, Don't know if this is too far off from the current UN*X we know but I never understood why we don't have the following one (and last as far as manipulating inodes is concerned) new system call: int chstat(ulong_t *flags, union ch_target target, struct stat *change); Flags tells what we would like to change and is a combination of the following: #define CH_OWN 0x00000001 #define CH_GRP 0x00000002 #define CH_MOD 0x00000004 #define CH_FLAGS 0x00000008 #define CH_ATIME 0x00000010 #define CH_MTIME 0x00000020 #define CH_CTIME 0x00000040 /* perhaps not this one... */ #define CH_SIZE 0x00000080 #define CH_FD 0x20000000 #define CH_PATH 0x40000000 #define CH_SELF 0x80000000 /* to not follow a final symlink */ When chstat returns an error, bits in *flags can indicate what changes caused the problem. Perhaps an extra flag CH_ATOMIC could be added to request an all-or-nothing operation. The flags approach also allows us to add optional arguments in the future. So maybe we could even have something like this, requiring an optional fourth argument char *ltarget to the chstat system call: #define CH_LTARG 0x00000100 /* to atomically change the */ /* target of a symbolic link */ int chstat(ulong_t *flags, union ch_target target, struct stat *change, char *ltarget); The union target specifies how we address the inode, by name, file descriptor or whatever we may want to think of. union ch_target { char *path; int fd; ... /* who knows what else in the future */ }; The (struct stat *) change points at the /* ** the system call itself, the int contains CH_* flags, ** the union addresses the target inode by name or filedescriptor ** and of the struct stat those members will be taken that are ** addressed by the bitmask */ This could eventually replace [fl]chown, [fl]chmod, [f]chflags, [fl]utimes and [f]truncate (hope I did not forget some) system calls which could be emulated by library functions. We don't need to open an inode if we don't want to and making the chstat() call available to applications could speed up such programs as cp, mv, tar, cpio, pax and restore when they are able to combine multiple changes into one system call. The argument flags could also be If I'm running too fast, please forgive me and ignore this message but the discussion about adding more system calls becoming a problem made me feel this is the right time to share my thoughts on this. Regards, Paul Schenkeveld, Consultant PSconsult ICT Services BV On Sun, Jul 22, 2001 at 05:16:11PM -0700, Bakul Shah wrote: > > > I guess there is general agreement that it is desirable to be able to set > > > schg,sunlink etc on symlinks and fifos. > > > Probably devices, too, which is a can of worms, particularly > > with devfs. > > > Already, the fchown/fchmod on sockets and other things which > > use a non VFS struct fileops fails -- I think this includes > > FIFO's. > > > > The consistency argument goes like this: > > > > > > Currently exposed as accessor methods to VOP_SETATTR are: > > > chmod(2), fchmod(2), lchmod(2) > > > chown(2), fchown(2), lchown(2) > > > chflags(2), fchflags(2) > > > > I know the argument for adding more and more system calls; > > I just don't agree with it. BSDI has already suggested > > limiting the total number of FreeBSD system calls to something > > like less than 32 more, total, without going to another block > > much higher up, and having to have FreeBSD allocate a large, > > sparse system call array, adding potentially a lot of overhead, > > depending on future directions with the ABI. > > Well, I won't mind if {,l}ch{mod,own,flags} etc become library > routines. Something like: > > int > chown(const char* path, uid_t owner, gid_t group) { > int fd, err; > > fd = open(path, O_EXCL); > if (!fd) > return errno; > err = fchown(fd, owner, group); > close(fd); > return err; > } > > But then you must be able to open() a symlink (O_NOFOLLOW > flag must not make the open fail). > > My main argument is for consistent treatment and for `equal > rights': if an object has an inode it must have the same > rights as any other object also with an inode. devfs is a > different kind of beast just like msdosfs so rights of an > inode based object are not the same as rights of devfs or > msdos fs. Anyway, I argue for either adding a syscall or > deleting a few to make a consistent set! > > Earlier you said: > > If the chflags call was defined to always affect its > > target (and not follow links), then the user space utility > > could do the stat/readlink itself, and find the correct > > target, if it wasn't told to not follow links. > > I don't like running namei twice. Between the stat/readlink > and chflags(), things can change. > > [Digressing a bit...] > Ideally I want only the f* version of syscalls, so that you > _have_ to `open' an object. Open gives you a handle, a > 'capability' to operate on the object. In the past I have > argued for *always* passing in a capability even for open(). > Then you can throw away even the chdir() call. But then > it won't be the unix we know and love and hate! > > -- bakul > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jul 28 10:12:57 2001 Delivered-To: freebsd-fs@freebsd.org Received: from kestrel.coleman.org (adsl-209-233-238-136.dsl.snfc21.pacbell.net [209.233.238.136]) by hub.freebsd.org (Postfix) with ESMTP id DDB4C37B403 for ; Sat, 28 Jul 2001 10:12:53 -0700 (PDT) (envelope-from don@kestrel.coleman.org) Received: from kestrel.coleman.org (eozoon.coleman.org [127.0.0.1] (may be forged)) by kestrel.coleman.org (8.10.1/8.10.1) with ESMTP id f6SHCpu22322; Sat, 28 Jul 2001 10:12:51 -0700 (PDT) Message-Id: <200107281712.f6SHCpu22322@kestrel.coleman.org> X-Mailer: exmh version 2.4 05/15/2001 with nmh-1.0.4 To: Chuck McCrobie Reply-To: don@coleman.org Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Softupdates & NFS semantics In-reply-to: Your message of "Sat, 28 Jul 2001 00:49:58 EDT." <3B624476.92A36689@cablespeed.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Jul 2001 10:12:50 -0700 From: Don Coleman Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've actually just been working on this for BSD/OS. Yes, you are correct, NFS server semantics is broken in FreeBSD when softupdates is enabled. If the server crashes prior to pushing the update onto the physical disk, say after creating a file, when it comes back up the file will not exist. BSD/OS 4.3 has this fixed... it's not hard, you basically just call VOP_FSYNC() on the vnode which has been changed (and call bioops.io_fsync() on the vnode if the directory entry has changed). Be sure you have the very latest softdep code. Note that there is really no reason to have softupdates enabled on a filesystem, if it's primary use is for NFS export, as the above changes defeat most of the advantages of softupdates, and adds some extra work (definitely not good on a CPU starved system). don To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jul 28 13:52: 8 2001 Delivered-To: freebsd-fs@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-169-104-149.dsl.lsan03.pacbell.net [64.169.104.149]) by hub.freebsd.org (Postfix) with ESMTP id E227B37B401 for ; Sat, 28 Jul 2001 13:52:04 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 3950066B25; Sat, 28 Jul 2001 13:52:04 -0700 (PDT) Date: Sat, 28 Jul 2001 13:52:03 -0700 From: Kris Kennaway To: Matthew Emmerton Cc: Kris Kennaway , fs@FreeBSD.ORG Subject: Re: [viro@math.psu.edu: Locally exploitable races in OpenBSD VFS] Message-ID: <20010728135203.A75957@xor.obsecurity.org> References: <20010723202526.B96630@xor.obsecurity.org> <002b01c113f0$df8e7aa0$1200a8c0@gsicomp.on.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002b01c113f0$df8e7aa0$1200a8c0@gsicomp.on.ca>; from matt@gsicomp.on.ca on Mon, Jul 23, 2001 at 11:29:39PM -0400 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 23, 2001 at 11:29:39PM -0400, Matthew Emmerton wrote: >=20 > > Has anyone looked at whether these apply to us? > > > > Kris >=20 > > > ----- Forwarded message from Alexander Viro ----- > > > > > > > > > [ snip ] > > > ... Moreover, the same bugs had been fixed in FreeBSD half a year ago. > ... > > > >=20 > Does that answer your question? Oops, I guess it does :-) I can delete that mail, then. Kris --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7YyXyWry0BWjoQKURAhCoAKC/gX2sWBZySmma+DkdKvALcFCWcgCg7yyq TzzWztHG1bK1EPXWrs92N2c= =VFGK -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jul 28 13:53:34 2001 Delivered-To: freebsd-fs@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 3629937B401 for ; Sat, 28 Jul 2001 13:53:30 -0700 (PDT) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 4572981D05; Sat, 28 Jul 2001 15:53:30 -0500 (CDT) Date: Sat, 28 Jul 2001 15:53:30 -0500 From: Alfred Perlstein To: Kris Kennaway Cc: Matthew Emmerton , fs@FreeBSD.ORG Subject: Re: [viro@math.psu.edu: Locally exploitable races in OpenBSD VFS] Message-ID: <20010728155330.M26571@elvis.mu.org> References: <20010723202526.B96630@xor.obsecurity.org> <002b01c113f0$df8e7aa0$1200a8c0@gsicomp.on.ca> <20010728135203.A75957@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010728135203.A75957@xor.obsecurity.org>; from kris@obsecurity.org on Sat, Jul 28, 2001 at 01:52:03PM -0700 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Kris Kennaway [010728 15:52] wrote: > On Mon, Jul 23, 2001 at 11:29:39PM -0400, Matthew Emmerton wrote: > > > > > Has anyone looked at whether these apply to us? > > > > > > Kris > > > > > > ----- Forwarded message from Alexander Viro ----- > > > > > > > > > > > > [ snip ] > > > > ... Moreover, the same bugs had been fixed in FreeBSD half a year ago. > > ... > > > > > > > > Does that answer your question? > > Oops, I guess it does :-) I can delete that mail, then. Actually, can you reforward me a copy? I want to make sure the work Tanimura and I are doing is safe for multithreaded smp. -- -Alfred Perlstein [alfred@freebsd.org] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message From owner-freebsd-fs Sat Jul 28 14:22:27 2001 Delivered-To: freebsd-fs@freebsd.org Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by hub.freebsd.org (Postfix) with ESMTP id 978A337B405; Sat, 28 Jul 2001 14:22:12 -0700 (PDT) (envelope-from pwd@apple.com) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id OAA05005; Sat, 28 Jul 2001 14:22:12 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Sat, 28 Jul 2001 14:20:09 +0100 Received: from [17.219.158.162] (lightning.apple.com [17.219.158.162]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id OAA04749; Sat, 28 Jul 2001 14:21:55 -0700 (PDT) User-Agent: Microsoft-Entourage/9.0.2509 Date: Sat, 28 Jul 2001 14:21:54 -0700 Subject: Re: flags on symlinks From: Pat Dirks To: Paul Schenkeveld , Bakul Shah Cc: , Message-ID: In-Reply-To: <20010728171214.A52461@psconsult.nl> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, Funny you should mention such a call. When we were faced with supporting access to get and set all the various file attributes that Mac OS supports on HFS/HFS+ volumes in Apple's Mac OS X kernel we decided to implement two new system calls: int getattrlist (const char* path, void* attrlist, void *buffer, size_t length, unsigned long options); And int setattrlist ( ... ); [same arguments] Where "attrlist" is a pointer to a block of flags 5 longwords of flags (separate flags for directory, file, and common information, for instance), buffer/length specify a block of attribute information to be filled in (in the case of getattrlist) or set (in the case of setattrlist), and "options" allows for the specification of options such as FSOPT_NOFOLLOW, which specify operation on a symlink ITSELF rather than following it. The semantics are very much along the lines you envision, except that the information is packed into a separate buffer whose size is determined by the attribute information being passed. It's worked out to be a very flexible mechanism for getting attribute information in and out of the system. We've expanded the list of defined attributes since it was first implemented with good success (there's no need to redefine the buffer structure being passed, so binary compatibility has been no problem). If you're curious about the implementation, have a look at the Darwin sources, or drop me a line. Cheers, -Pat Dirks Mac OS X Filesystems Tech Lead. On 7/28/01 8:12 AM, "Paul Schenkeveld" wrote: > Guys, > > Don't know if this is too far off from the current UN*X we know but > I never understood why we don't have the following one (and last as > far as manipulating inodes is concerned) new system call: > > int chstat(ulong_t *flags, union ch_target target, > struct stat *change); > > Flags tells what we would like to change and is a combination of the > following: > > #define CH_OWN 0x00000001 > #define CH_GRP 0x00000002 > #define CH_MOD 0x00000004 > #define CH_FLAGS 0x00000008 > #define CH_ATIME 0x00000010 > #define CH_MTIME 0x00000020 > #define CH_CTIME 0x00000040 /* perhaps not this one... */ > #define CH_SIZE 0x00000080 > > #define CH_FD 0x20000000 > #define CH_PATH 0x40000000 > #define CH_SELF 0x80000000 /* to not follow a final symlink */ > > When chstat returns an error, bits in *flags can indicate what > changes caused the problem. Perhaps an extra flag CH_ATOMIC could > be added to request an all-or-nothing operation. > > The flags approach also allows us to add optional arguments in the > future. So maybe we could even have something like this, requiring > an optional fourth argument char *ltarget to the chstat system call: > > #define CH_LTARG 0x00000100 /* to atomically change the */ > /* target of a symbolic link */ > > int chstat(ulong_t *flags, union ch_target target, > struct stat *change, char *ltarget); > > The union target specifies how we address the inode, by name, file > descriptor or whatever we may want to think of. > > union ch_target { > char *path; > int fd; > ... /* who knows what else in the future */ > }; > > The (struct stat *) change points at the > > /* > ** the system call itself, the int contains CH_* flags, > ** the union addresses the target inode by name or filedescriptor > ** and of the struct stat those members will be taken that are > ** addressed by the bitmask > */ > > This could eventually replace [fl]chown, [fl]chmod, [f]chflags, > [fl]utimes and [f]truncate (hope I did not forget some) system > calls which could be emulated by library functions. > > We don't need to open an inode if we don't want to and making the > chstat() call available to applications could speed up such programs > as cp, mv, tar, cpio, pax and restore when they are able to combine > multiple changes into one system call. > > The argument flags could also be > > If I'm running too fast, please forgive me and ignore this message > but the discussion about adding more system calls becoming a problem > made me feel this is the right time to share my thoughts on this. > > Regards, > > Paul Schenkeveld, Consultant > PSconsult ICT Services BV > > On Sun, Jul 22, 2001 at 05:16:11PM -0700, Bakul Shah wrote: >>>> I guess there is general agreement that it is desirable to be able to set >>>> schg,sunlink etc on symlinks and fifos. >> >>> Probably devices, too, which is a can of worms, particularly >>> with devfs. >> >>> Already, the fchown/fchmod on sockets and other things which >>> use a non VFS struct fileops fails -- I think this includes >>> FIFO's. >> >>>> The consistency argument goes like this: >>>> >>>> Currently exposed as accessor methods to VOP_SETATTR are: >>>> chmod(2), fchmod(2), lchmod(2) >>>> chown(2), fchown(2), lchown(2) >>>> chflags(2), fchflags(2) >>> >>> I know the argument for adding more and more system calls; >>> I just don't agree with it. BSDI has already suggested >>> limiting the total number of FreeBSD system calls to something >>> like less than 32 more, total, without going to another block >>> much higher up, and having to have FreeBSD allocate a large, >>> sparse system call array, adding potentially a lot of overhead, >>> depending on future directions with the ABI. >> >> Well, I won't mind if {,l}ch{mod,own,flags} etc become library >> routines. Something like: >> >> int >> chown(const char* path, uid_t owner, gid_t group) { >> int fd, err; >> >> fd = open(path, O_EXCL); >> if (!fd) >> return errno; >> err = fchown(fd, owner, group); >> close(fd); >> return err; >> } >> >> But then you must be able to open() a symlink (O_NOFOLLOW >> flag must not make the open fail). >> >> My main argument is for consistent treatment and for `equal >> rights': if an object has an inode it must have the same >> rights as any other object also with an inode. devfs is a >> different kind of beast just like msdosfs so rights of an >> inode based object are not the same as rights of devfs or >> msdos fs. Anyway, I argue for either adding a syscall or >> deleting a few to make a consistent set! >> >> Earlier you said: >>> If the chflags call was defined to always affect its >>> target (and not follow links), then the user space utility >>> could do the stat/readlink itself, and find the correct >>> target, if it wasn't told to not follow links. >> >> I don't like running namei twice. Between the stat/readlink >> and chflags(), things can change. >> >> [Digressing a bit...] >> Ideally I want only the f* version of syscalls, so that you >> _have_ to `open' an object. Open gives you a handle, a >> 'capability' to operate on the object. In the past I have >> argued for *always* passing in a capability even for open(). >> Then you can throw away even the chdir() call. But then >> it won't be the unix we know and love and hate! >> >> -- bakul >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-fs" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message