On Thu, Oct 30, 2003 at 07:41:01PM -0500, Thor Lancelot Simon wrote:
  | On Fri, Oct 31, 2003 at 12:25:07AM +0000, David Laight wrote:
  | > 
  | > I think that disklabel(8) ought to be able to write the label in all
  | > formats on any format without requiring any kernel code.  It should
  | > probably overwrite any old label by default as well.
  | > Then the kernel can be changed to play 'hunt the disklabel' for reading
  | > and have the code that writes labels removed entirely.
  | > (The 'write label' code would need to be in (say) libutil, so other
  | > programs can use it.)
  | 
  | I'm concerned that removing all knowledge of the disklabel structure from
  | the kernel will ultimately result in a situation in which it's impossible
  | to enforce the restrictions on partition access used to protect the TCB
  | when running at securelevel > 0.  
  | 
  | In fact, I tend to think that _all_ disklabel access should be mediated by 
  | the kernel, using a suitably abstracted interface, and that access to the 
  | label sectors should be explicitly forbidden to all userland programs.  I
  | have seen various proposals for alternate schemes but I have never seen
  | one (the present scheme included) which protects the integrity of the
  | partitioning information even against a rogue process operating with root
  | privileges -- and if you can't trust the partitioning information, the rest
  | of the integrity guarantees are pretty much shot to hell as well.

Part of the problem is that DIOCWDINFO (update in-core, then update raw)
_fails_ if there isn't an existing raw label.  So disklabel(8) -r has to
be used to create the raw label.  Which in itself is fraught with
difficulties (due to obscure inconsistencies between how disklabel -r -I
and disklabel -r -R operate).  Thus, if you're doing work with disks
from C, the best thing to do at this time is to make the label writable
with DIOCWLABEL, and pread()/pwrite() the labelsector yourself...

That all said, if DIOCWDINFO was change to _not_ fail if there's
no existing raw label and just write it anyway (my preferred,
unless there's security/integrity ramifications I am not aware of),
or we added a new ioctl to create the raw label, then things would
be much better.  In either case, a chunk of disklabel(8) could
be simplified and it would makes third party manipulation of disklabels
from C programs more robust.

Luke.
(who's spent too much time recently dealing with disklabel issues)