[lkml]   [1999]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Improving the Unix API

    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 from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:52    [W:0.019 / U:8.420 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site