[10:51:02]  <davidz> walters: hey
   [10:51:11]  <davidz> so as part of the new PolicyKit release
   [10:51:51]  <davidz> I'm doing something like this:
   http://people.freedesktop.org/~david/pkexec-1.png
   [10:51:59]  <davidz> e.g. a 'sudo' command for polkit
   [10:52:23]  <davidz> some background on that before I get to what I want
   to discuss here
   [10:52:32]  ***  shaunm has left chat #fedora-desktop (Ex-Chat).
   [10:52:32]  <davidz> pkexec exists for two reasons
   [10:52:49]  <davidz> 1. users wants to do stuff like 'sudo gedit
   /etc/hosts' to work
   [10:53:05]  <davidz> 2. sometimes you need to run a privileged helper
   [10:53:08]  <jclinton> how will "Run As" get translated if it is not root?
   [10:53:29]  <jclinton> ie. is the phrase "Super User" hardcoded
   [10:53:37]  <davidz^ (in a sec)
   [10:54:34]  <davidz> as an example of 2., consider Eclipse... I talked to
   the Eclipse guys about this.. they want to run oprofile as root... in a
   very controlled fashion.. so the idea is that they can drop a polkit XML
   file saying "use the action org.eclipse.profiler.run-oprofile' for this
   that specifies that running /usr/libexec/eclipse/run-oprofile' should use
   this action
   [10:54:58]  <davidz> then they can grant authorizations for this action...
   including sane defaults like allowing people at the console to do stuff by
   default without a password
   [10:55:26]  <davidz> so it's basically just fine-grained sudo without all
   the sudo configuration file nightmare things
   [10:55:41]  <davidz> including using another polkit backend to decide if
   the caller is authorized
   [10:55:51]  <davidz> e.g. directory server, roles, groups, all that crap
   [10:56:13]  <davidz> jclinton: right now the phrase "Super User" is
   hardcoded
   [10:56:24]  <davidz> can change that, just trying to illustrate the point
   [10:56:36]  <davidz> walters: anyway, so I was looking at our old friend
   the session bus
   [10:56:44]  <davidz> for case 1.
   [10:57:13]  <davidz> e.g. suppose you start gedit as uid 0 using pkexec -
   should it be able to talk to the session bus already running as uid 500?
   [10:58:12]  <davidz> so I tried doing that.. first of all,
   /etc/dbus-1/session.conf needs <allow user="root"/>
   [10:58:20]  <davidz> then things are actually sorta peachy
   [10:58:44]  <davidz> e.g. 'pkexec xterm' and then 'gvfs-mount -li' (which
   talks to the gvfs volume monitors on the session bus) just works
   [10:59:05]  <davidz> so that means the file chooser is kinda sane... you
   get to see the same mounts as in your normal session
   [10:59:16]  <davidz> lots of other stuff break though... especially
   single-instance stuff
   [10:59:19]  <davidz> gnome-terminal in particular
   [10:59:31]  <davidz> walters: so I guess my question is what your thoughts
   on this are?
   [10:59:52]  <davidz> it's a really hard question I think... there's no
   good answer, it's still on the level of "have to figure out this stuff"...
   [11:00:17]  <davidz> (also, we want to patch the WM to display RED window
   decorations for windows from other uids)
   [11:00:58]  <halfline> davidz: hmm
   [11:01:15]  <halfline> davidz: do we really want to allow things like
   pkexec gedit ?
   [11:01:50]  <davidz> there's actually a D-Bus bug about this... lemme find
   it
   [11:01:52]  <halfline> sounds fishy. the whole point of policykit is to
   keep the toolkit code separate from the mechanism and unprivileged right?
   [11:02:08]  <davidz> halfline: yeah, that's the long term goal
   [11:02:23]  <davidz> including teaching GVfs about polkit
   [11:02:51]  <davidz> so e.g. 'gedit /etc/hosts' works
   [11:02:51]  <davidz> e.g. make GFile user a helper if it gets EPERM
   [11:02:53]  <davidz> alexl_away blogged about that
   [11:02:59]  <davidz> no-one has gotten around to this yet
   [11:03:14]  <davidz> halfline: so pkexec is really just a geek-comfort for
   the interim
   [11:03:23]  <davidz> and it's needed for stuff like 2. anyway
   [11:03:40]  <davidz> e.g. we want to make it simple for e.g. Eclipse to
   run oprofile or whatever
   [11:04:14]  <halfline> one thing to think about...
   [11:04:17]  <halfline> sudo clears the environment
   [11:04:24]  <davidz> sure, I do the same
   [11:04:25]  <halfline> should pkexec ?
   [11:04:26]  <davidz> of course
   [11:04:31]  <davidz> right
   [11:04:34]  <halfline> then how are you finding DBUS_SESSION_BUS_ADDRESS ?
   [11:04:47]  <davidz>   const gchar *environment_variables_to_save[] = {
   [11:04:47]  <davidz>     "DESKTOP_STARTUP_ID",
   [11:04:47]  <davidz>     "DISPLAY",
   [11:04:47]  <davidz>     "HOME",
   [11:04:47]  <davidz>     "LANG"
   [11:04:47]  <davidz>     "LANGUAGE",
   [11:04:49]  <davidz>     "LC_ALL",
   [11:04:51]  <davidz>     "LC_MESSAGES",
   [11:04:53]  <davidz>     "SHELL",
   [11:04:55]  <davidz>     "TERM",
   [11:04:57]  <davidz>     "XAUTHORITY",
   [11:04:59]  <davidz> #if 0
   [11:05:01]  <davidz>     "DBUS_SESSION_BUS_ADDRESS",
   [11:05:03]  <davidz>     "ORBIT_SOCKETDIR",
   [11:05:05]  <davidz> #endif
   [11:05:07]  <davidz>     NULL
   [11:05:11]  <davidz> halfline: I save some of the variables
   [11:05:21]  <davidz> so e.g. LD_PRELOAD won't get through ;-)
   [11:05:35]  <davidz> I mean, this is just standard stuff if you write
   secure programs
   [11:05:54]  <halfline> hmm, but if you want pkexec generic-gui-app to keep
   working
   [11:05:56]  <davidz> halfline: anyway, maybe the answer is simply that we
   don't set DISPLAY or DBUS_SESSION_BUS_ADDRESS at all in pkexec
   [11:05:58]  <halfline> then that list isn't sufficient
   [11:06:05]  <davidz> then of course 'pkexec gedit' won't work
   [11:06:15]  <halfline> davidz: yea i think that's a better call
   [11:06:17]  <davidz> halfline: maybe not (what do you think is missing?)
   [11:06:27]  <halfline> KRB5_CCNAME was the one i thought of immediately
   [11:06:59]  <davidz> halfline: but people are still going to want to run
   X11 apps as root for one reason or another.... so I don't think it's
   realistic to stop them doing so
   [11:07:37]  <davidz> of course the defaults in the OS and the features we
   provide (e.g. make GVfs use a setuid helper so things like 'gedit
   /etc/hosts' work) should hopefully minimize the need for this
   [11:08:12]  <halfline> well if people really want to be able to do it,
   they can always work around it
   [11:08:30]  <halfline> pkexec env DISPLAY=$DISPLAY gedt
   [11:08:33]  <halfline> *gedit
   [11:08:35]  <halfline> or whatever
   [11:08:43]  <davidz> I don't think putting roadblocks up and requiring
   them to work around it is going to help
   [11:08:46]  <davidz> then people just get annoyed
   [11:08:56]  <davidz> we should instead just make sure it's not needed
   [11:08:58]  <halfline> well my thinking is... the real reason for this is
   the eclipse case right?
   [11:09:05]  <davidz> and also do things like red decorations if they are
   [11:09:07]  <halfline> and this other stuff is kind of like icing
   [11:09:09]  <davidz> halfline: right
   [11:09:33]  <davidz> well, any program where you need to do stuff as uid 0
   and where you don't want to write a full-fledged system daemon using D-Bus
   to do this....
   [11:09:47]  <davidz> I mean, it's a bit overkill the way we have done some
   things already
   [11:09:54]  <davidz> like gnome-system-monitor and kill/renice
   [11:09:57]  ***  shaunm (~shaunm@proxyserver.wolfram.com) has joined chat
   #fedora-desktop.
   [11:09:58]  ***  shaunm has been oped by Rupert.
   [11:10:05]  <davidz> we have a dbus system service that is activated on
   demand
   [11:10:07]  <davidz> to do this
   [11:10:09]  ***  jg has left chat #fedora-desktop (Read error: 145
   (Connection timed out)).
   [11:10:19]  <davidz> I expect we can replace that with 'pkexec kill 42'
   instead...
   [11:10:36]  <davidz> so, just simpler all around
   [11:10:49]  <halfline> i guess the key point here is, the only time this
   is useful is in cases where the thing after the pkexec is already small
   and self contained
   [11:10:57]  <davidz> right
   [11:10:59]  <davidz> and secure
   [11:11:01]  <halfline> otherwise it's just like consolehelper all over
   again
   [11:11:09]  <halfline> or gksudo or whatever
   [11:11:15]  <davidz> yeah
   [11:11:24]  <davidz> maybe I shouldn't care about doing 1. at all
   [11:11:30]  <davidz> I mean, it's a rat hole
   [11:11:36]  <halfline> yea
   [11:11:39]  <halfline> that's what i'm thining
   [11:11:39]  <davidz> people can just use sudo for now
   [11:11:56]  <halfline> it was just icing anyway
   [11:12:14]  <halfline> and people already have workflows to get that icing
   a different way
   [11:12:29]  <halfline> it has security implications and functionality
   implications
   [11:12:38]  <halfline> i mean things aren't going to generally work in
   that environment
   [11:13:02]  <halfline> pkexec strikes me as much more useful for specific
   targeted, confined cases
   [11:13:15]  <davidz> it just seems very convenient
   [11:13:15]  <davidz> to add this
   [11:13:15]  <davidz> plus you'll get the policy for free
   [11:13:15]  <davidz> instead of admins having to somehow get 10,000 copies
   of /etc/sudoers on their machines
   [11:13:17]  <davidz> (e.g. managing 10,000 machines)
   [11:13:19]  <davidz> so I think it just might be worth it anyway
   [11:13:23]  <davidz> right
   [11:13:25]  <davidz> things work very poorly right now
   [11:13:52]  <halfline> not only do things work poorly but i feel like time
   shouldn't be spent fixing them to work
   [11:13:52]  <davidz> well, yeah
   [11:13:59]  <davidz> but geek-comfort is pretty important too
   [11:14:16]  <davidz> I mean, people are going to run X11 crap as root;
   they're not going to stop
   [11:14:20]  <hughsie> ajax: ping, hey dude. if I'm trying to debug a "why
   does my tv print out-of-range when i connect it to my laptop using a
   hdmi->dvi cable" type problem, have you got any pointers? the only mode it
   displays okay is 800x600@60Hz and that's no fun on a 26" screen
   [11:14:31]  <halfline> davidz: i mean we alreayd disabled logging in as
   root from gdm
   [11:14:42]  <davidz> halfline: that's a good start
   [11:14:44]  <halfline> davidz: and gconf no longer works across a su
   [11:15:04]  <davidz> halfline: actually if you just allow uid 0 to connect
   to the session bus it will
   [11:15:29]  <davidz> we should at the very least paint the WM decorations
   in a scary red color
   [11:15:32]  <halfline> davidz: there's dragons there though...
   [11:15:35]  <davidz> if a X client is uid 0
   [11:15:41]  <halfline> davidz: what if a root app ends up activating
   gconfd?
   [11:15:48]  <davidz> halfline: that's more because of how gconf works
   [11:16:04]  <halfline> right my point is gconf isn't designed to be run
   that way
   [11:16:05]  <davidz> halfline: a question is whether future software
   architectures allow this kind of thing
   [11:16:10]  <davidz> I think, maybe they should
   [11:16:13]  <davidz> I don't really know
   [11:16:21]  <hughsie> ajax: relevant xorg.0.log snippet here:
   http://fpaste.org/paste/12026
   [11:16:26]  <halfline> but you were saying this is for a near term geek
   convenience
   [11:16:33]  <davidz> I mean, it's all good that we say "oh noz, don't do
   that" but it won't stop customers and users from filing bugs
   [11:16:38]  <halfline> and the long term plan is to keep ui code
   unprivileged
   [11:16:45]  <halfline> and only mechanism privileged
   [11:17:02]  <davidz> so maybe I don't do 1. initially
   [11:17:11]  <davidz> but I think it's worth thinking about this
   [11:17:15]  <davidz> because it's not going away
   [11:17:17]  <halfline> sure
   [11:17:26]  <halfline> the nsa has some metacity patches i think btw
   [11:17:31]  <davidz> also related is the whole "X clients from different
   hosts"
   [11:17:34]  <halfline> for showing things running under different contexts
   differently
   [11:18:55]  <ajax> hughsie: weeird, there's not even any funny interlacing
   business going on there
   [11:19:13]  <ajax> also, a 1050p tv?  who decided that was a good idea.
   [11:19:18]  <hughsie^ it's a sony consumer tv if that helps
   [11:19:31]  <davidz> halfline: maybe another answer to "want to run X11
   apps as other uid" is to start up a whole new session including a X server
   - and just run it rootless on top of your current session - maybe bridge
   the session buses somehow
   [11:19:44]  <davidz> but then you have other problems as well
   [11:19:46]  <hughsie> ajax: where do i look to help debug this? got any
   pointers?
   [11:19:51]  <davidz> so, yeah, hard problem
   [11:19:57]  <ajax> hughsie: heh, it claims to be LG.
   [11:20:03]  * davidz decides not to work on that problem for now
   [11:20:09]  * davidz disables support for use case 1
   [11:20:19]  <hughsie> ajax: heh, probably an lg panel with sony plastic...
   [11:20:43]  <ajax> well, "Goldstar", but we all know who that is.
   [11:20:43]  <hughsie^ ohh, wait
   [11:20:55]  <hughsie> my other monitor is an lg
   [11:21:08]  <davidz+ oh, Goldstar... are they still around? I had a
   Goldstar CRT blow up on me some 15 years ago
   [11:21:08]  <hughsie> and i removed that dvi and plugged in the tv
   [11:21:10]  <ajax> you sneaky person you!
   [11:21:35]  <hughsie^ so.... isn't plugging in the dvi supposed to probe
   for new modes?
   [11:21:53]  <hughsie> i'm guessing it's thinking the new panel is the old
   monitor
   [11:21:57]  <ajax> davidz: LG == Lucky Goldstar, yeah
   [11:22:12]  <hughsie> yup, the same resolutions are listed for my monitor
   [11:22:27]  <hughsie> so the new panel capabilities are not being
   probed...
   [11:22:29]  <ajax^ it certainly should do.  kms or not?
   [11:22:35]  <hughsie> kms
   [11:22:43]  <hughsie> latest f11 with updates
   [11:23:07]  <hughsie> how do i test if i'm getting unplug and plug events/
   [11:23:28]  <ajax> we don't actually respond to that automagically yet. 
   on the list.
   [11:23:38]  <ajax> but, running 'xrandr -q' should refresh the mode list.
   [11:23:53]  <ajax> if it doesn't then something's getting cached in the
   kernel somewhere and i get angry
   [11:25:20]  <hughsie^ no, xrandr -q doesn't refresh the list
   [11:25:28]  ***  walters has left chat #fedora-desktop (Ping timeout: 600
   seconds).
   [11:25:29]  <ajax> lovely
   [11:25:36]  <hughsie> i've got a feeling a reboot might fix this, but i
   don't think i should have to... :-)
   [11:25:42]  <ajax> quite!
   [11:26:01]  <hughsie^ ahh, in dmesg:
   [11:26:01]  <hughsie> i2c-adapter i2c-2: unable to read EDID block.
   [11:26:01]  <hughsie> i915 0000:00:02.0: DVI-D-1: no EDID data
   [11:26:36]  <ajax> on the motherboard, is this an hdmi or a dvi port?
   [11:26:55]  <hughsie^ it's a docked t61, with the dvi cable connected to
   the dock dvi port
   [11:27:22]  <hughsie> the port works fine on my 21" LG monitor
   [11:27:31]  <davidz> halfline: fwiw,
   https://bugs.freedesktop.org/show_bug.cgi?id=17970 got a lot of clueful
   comments
   [11:27:41]  <hughsie> but that's dvi->dvi, rather than dvi->hdmi if that
   matters
   [11:28:33]  <ajax> well, the cable doesn't matter.  electrically they're
   the same.  but the transceiver on the mobo (or dock in this case) is
   different for true hdmi connectors, and there's been some bugs in that
   area recently.
   [11:29:05]  <hughsie^ no, the port is a dvi port in both cases. to connect
   to the dv it's using a dvi to hdmi cable
   [11:29:08]  <ajax> (actually, electrically hdmi is a superset, it has one
   more pin and a higher crossover frequency, but that doesn't matter here)
   [11:29:26]  <ajax> yeah, shame.  was hoping that was it.
   [11:30:19]  <hughsie^ so how come the EDID gets sent for the monitor, and
   not the tv?
   [11:30:43]  <halfline> davidz: oh yea that bug
   [11:31:58]  <ajax> it doesn't get sent, it's something the host pulls.  if
   i had to guess, the dock DVI support is conflating "SDVO connected" with
   "DVI connected", and then trying to elide EDID fetches when there's not
   been a change in connection state.
   [11:32:03]  <davidz> halfline: anyway, it's not a problem in Fedora - we
   don't have any remotely useful stuff that needs to run as uid 0 these days
   [11:32:11]  <ajax> sdvo being the expansion bus that gets you to the DVI
   transceiver on the dock
   [11:32:28]  <ajax> so, let's test that theory.  undock, xrandr -q, redock,
   xrandr -q.
   [11:32:40]  <davidz> halfline: I just wish someone would clean up the
   livecd so we don't install any of the system-config-* programs (at least
   the ones using consolehelper)