Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Jun 1999 12:19:02 -0400 (EDT)
From:      Alexander Viro <viro@math.psu.edu>
To:        Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
Cc:        Francois-Rene Rideau <fare@tunes.org>, Linux Kernel <linux-kernel@vger.rutgers.edu>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, NetBSD Kernel <tech-kern@netbsd.org>
Subject:   Re: Improving the Unix API 
Message-ID:  <Pine.GSO.4.10.9906271154530.24019-100000@weyl.math.psu.edu>
In-Reply-To: <199906271239.MAA22238@orchard.arlington.ma.us>

next in thread | previous in thread | raw e-mail | index | archive | help


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.9906271154530.24019-100000>