From owner-freebsd-hackers Sun Jun 27 9:19:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from math.psu.edu (leibniz.math.psu.edu [146.186.130.2]) by hub.freebsd.org (Postfix) with ESMTP id 0770F14D8E for ; Sun, 27 Jun 1999 09:19:20 -0700 (PDT) (envelope-from viro@math.psu.edu) Received: from weyl.math.psu.edu (weyl.math.psu.edu [146.186.130.226]) by math.psu.edu (8.9.3/8.9.3) with ESMTP id MAA28069; Sun, 27 Jun 1999 12:19:03 -0400 (EDT) Received: from localhost (viro@localhost) by weyl.math.psu.edu (8.9.3/8.9.3) with ESMTP id MAA02595; Sun, 27 Jun 1999 12:19:02 -0400 (EDT) X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs Date: Sun, 27 Jun 1999 12:19:02 -0400 (EDT) From: Alexander Viro To: Bill Sommerfeld Cc: Francois-Rene Rideau , Linux Kernel , FreeBSD Hackers , NetBSD Kernel Subject: Re: Improving the Unix API In-Reply-To: <199906271239.MAA22238@orchard.arlington.ma.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 27 Jun 1999, Bill Sommerfeld wrote: > > .. but there remained one that garbled meta-data had made into a > > non-existing block device, that would resist rm -f. He realized > > that the device had an immutable attribute. However, the problem is > > that to change the attribute, you have to open the file before you > > can ioctl() on it; > > BSD4.4 and its progeny deal with this by providing both chflags() and > fchflags() system calls; as you don't need to be able to do an open() > call to use chflags(), you can just fix the immutable attribute once > you have the system running at an appropriate securelevel. Usage of ioctl() on Linux was a bad idea and it's going to be fixed. More or less in the same direction, not exactly the same - 4.4 chflags() works fine for UFS and leaves other filesystems to map what they can into the UFS set. Which is bogus - immutable is not a UFS attribute, it's VFS one. I have a patch (still pre-alpha) and I'll post it tomorrow or on Wednesday when I'll be back from CA. As for the opening with no permissions - well, it would make *big* sense if we could narrow down the API and move chown(), chmod(), etc. into libc leaving f-variants in the kernel. Binary compatibility... Extreme variant might include {set,get}sockopt extended to files and doing both *stat and *ch{mod,own,flags} via that. Out of curiosity - did somebody on *BSD side play with that? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message