blivet-gui announcement

[Simo Sorce]

On Fri, 2014-09-05 at 23:47 -0700, Adam Williamson wrote:
> On Fri, 2014-09-05 at 18:03 +0200, Lennart Poettering wrote:
> > On Fri, 05.09.14 11:52, Matthias Clasen (mclasen at redhat.com) wrote:
> > 
> > > On Fri, 2014-09-05 at 15:55 +0200, Vratislav Podzimek wrote:
> > > > On Fri, 2014-09-05 at 09:04 -0400, Bastien Nocera wrote:
> > > > > 
> > > > > ----- Original Message -----
> > > > > > Good news, everyone! We (me and CC'd Vojtech Trefny) would like to
> > > > > > introduce you the next generation tool for storage management -- the
> > > > > > **blivet-gui** tool [1]_. It is a GUI tool based on the blivet python
> > > > > > library (originally Anaconda's storage management and configuration
> > > > > > tool) inspired by GParted and other storage management tools. Why not
> > > > > > use GParted you ask?
> > > > > 
> > > > > Actually my question is "why not gnome-disk-utility?" :)
> > > > Because it doesn't work well with LVM, RAID, BTRFS and a combination of
> > > > them.
> > > 
> > > Leaving LVM out was an explicit decision, because of all the system
> > > integration problems with LVM. It works fine with RAID and btrfs as far
> > > as I know. Do you have any concrete complaints about the RAID or btrfs
> > > support in gnome-disk-utility ?
> > 
> > Also, note that gnome-disk-utility actually properly separates out the
> > unpriviliged UI from the priviliged backend in udisks.
> > 
> > In this day-and-age we should not write new programs anymore that
> > require the entire UI stack to run as root. We should really get away
> > from doing something like that. In the blivet-ui docs "su" is the
> > recommended way to invoke the program, and that's really wrong for a
> > graphical one.
> > 
> > gnome-disk-utility got that right. the new blivet ui did not. And this
> > is not something you can add as an afterthought, you actually need to
> > do your homework and split things up into privileged and
> > non-priviliged parts from the beginning.
> > 
> > The blivet-ui thing in this regard is certainly not an improvement over
> > g-d-u, it's a step back.
> 
> Well...I agree that in perfect theoretical engineering land, it'd be
> nice if blivet-gui had a better privilege model. I think you're being
> way too unnecessarily harsh, though, and missing a rather major point.
> 
> blivet-gui is not 100% new code. The new bit is just the relatively thin
> GUI wrapper. The really hard code - the bits that do the partitioning -
> has existed for 15+ years: it's anaconda's partitioning code (lately
> split out into python-blivet). And that code has *always* assumed it'll
> run as root, because it's part of an installer that always does.
> 
> If you want to use the blivet code as the base for a standalone GUI
> installer and add a better privilege model, that was always going to be
> a retrofitting job - even if you did it before doing this initial 0.1.x
> release of blivet-gui, you're still retrofitting. It's really not a
> significant difference.
> 
> I can believe it'd be hard work, but I think you overstate the case by a
> long way when you say it'd be impossible. It may be finicky work, but it
> seems unlikely that it'd be easier to write an entirely new partitioning
> app with all of blivet's capabilities from the ground up (with a good
> privilege model) than it would be to take advantage of all that existing
> code for doing the very difficult and complex work of partitioning, and
> retrofit a decent privilege model onto it.

well given blivet is a library, shouldn't it be simple enough to put it
behind a dbus interface and have the GUI and actual operation be
separated by dbus and authorized via mechanisms like polkit or similar ?

That should pretty much solve the privilege separation between gui and
core code.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York