09:02 mdz        Keybuk said he probably wouldn't be able to make it
09:03 mdz        and I expect the same for sabdfl as he's travelling
09:03 ogra       Seveas, obviously self chosen
09:04 mdz        I think we can call this a quorum though
09:04 mdz        there is one candidate for the core development team, Sebastian Drge
09:04 mjg59      Shall we get on with things, then?
09:04 mdz        is that slomo?
09:04 dholbach   slomo, are you there?
09:05 dholbach   mdz: yes
09:05 mdz        launchpad says yes
09:05 ogra       yup, thats slomo
=== janimo [] has joined #ubuntu-meeting
=== slomo_ [n=slomo@ubuntu/member/slomo] has joined #ubuntu-meeting
09:05 mdz        slomo_: hello
09:05 mdz        we were just looking for you
09:05 slomo_     hi everybody, hi mdz :)
09:06 slomo_     mdz: yes, ogra told me... sorry
09:07 mdz        slomo_: you mention on your wiki page that you maintain a package in
                 Debian; are you a DD or do you have a sponsor?
09:07 slomo_     mdz: currently i only have some sponsors but i want to apply for NM in some
09:08 mdz        slomo_: who are your sponsors?
09:08 slomo_     mdz: dajobe, ajmitch and lool
09:08 mdz        are any of them present?
09:09 mdz        maybe ajmitch, I'd like to hear from him
09:09 sistpoty   ajmitch said he'd be on his way to work 10mins ago
09:09 slomo_     he left only some minutes ago afaik :/ and the others are not present
09:09 mjg59      slomo_: Your wiki page lists a couple of packages that are also in Debian
                 (the musepack ones, from a quick search) - what the situation there?
09:10 mdz        slomo_: do you have any specific plans which require upload privileges for
                 mjg59: i definitly have to update my wiki page ;) the xmms-musepack was
09:10 slomo_     uploaded by someone else some weeks ago... but i plan to get my
                 bmp-musepack package in when i find a sponsor with some time... the other's
                 are ubuntu only atm and i've itps for them
09:11 mjg59      slomo_: Ok, cool
                 mdz: i want to work mostly on mono specific packages, helping ajmitch and
09:11 slomo_     tseng... but if some help is needed elsewhere i'm happy to help out
                 wherever i could be useful
09:11 ogra       mdz, we could drop xine on him ;)
09:11 ogra       slomo does a lot with multimedia packages
=== Burgwork [] has joined #ubuntu-meeting
09:12 \sh        slomo is a tough guy for the hard nuts ... MOTU owe him a few
09:12 mdz        slomo_: which packages, and what sort of work?
09:13 ajmitch_   morning
09:13 slomo_     mdz: for mono? the complete mono stack from ground up... i.e. cli-common,
                 mono, gtk#, monodoc, etc
=== ajmitch_ didn't realise there was a TB meeting today, sorry :)
=== Keybuk [] has joined #ubuntu-meeting
09:15 ogra       Keybuk!!
09:15 mdz        slomo_: what would you like to change about those packages presently?
09:16 mdz        Keybuk: (slomo, [11] applying for
                 mdz: get the latest stuff in, get everything working fine together and we
09:16 slomo_     plan to get some more mono specific packages like gtk#2 for example to main
                 for dapper
09:17 ajmitch_   mdz: what would you like to ask about the sponsored packages or other work?
09:17 mdz        slomo_: what is needed in order to get everything working well together?
09:17 mdz        ajmitch_: yes, feel free
09:18 ajmitch_   ok, slomo has done most of the mono work for dapper that was required for
                 merging debian changes
=== vincent_ [n=vincent@] has joined #ubuntu-meeting
09:18 ajmitch_   he's worked well with the debian mono team to get issues sorted out
09:19 ajmitch_   and the packages I've had time to sponsor have been very clean, with few
                 things to fix up or clarify
09:19 ajmitch_   I'd like to see him able to upload the mono stuff directly to main,
                 especially as we get more of it in
09:20 mdz        ajmitch_: thanks
                 mdz: slomo_ works on gst-plugins-multiverse, he seems to be good job to
09:20 seb128     coordinate with the main package and work with the Debian maintainer on
                 changes too
09:20 seb128     s/seems//
09:20 mdz        seb128: that's great ,thanks
09:20 seb128     s/seems to be/do/
09:20 ogra       and slomo mainly maintains mplayer nowadays
09:21 ogra       and ffmpeg etc ...
09:21 mdz        slomo_: are you still there?
                 mdz: mostly dependencies between those packages... they're very closely
09:21 slomo_     tied. or for example when when updated to mono 1.1.9 some packages broke
                 because of stricter compiler so these needed to be fixed too
09:21 mdz        slomo_: what can we do to make that situation better?
09:22 slomo_     mdz: sure, i needed to sort my thoughts a bit... i wasn't really prepared
                 for this right now ;) i didn't know there was a meeting
09:22 mdz        slomo_: if you would prefer to wait until the next meeting, that's no
09:22 slomo_     mdz: mostly work with upstream to get everything in a stable state
09:23 mdz        slomo_: I'm looking for specific and concrete actions that you would like
                 to take in main, as examples of what we could expect from you
09:23 ajmitch_   upstream being debian or real upstream of the programs that break?
                 mdz: ok... well, you could expect from me that i get the latest versions in
09:24 slomo_     until UVF, trying to keep breakages at the lowest level possible and get
                 some more mono specific packages from universe to main and caring for them
09:25 mdz        slomo_: how would this relate to the work that tseng is currently doing on
09:26 slomo_     mdz: i would do exactly the same stuff he does... we would share the work
                 between us to get more work done in shorter time
09:27 slomo_     ajmitch_: both
                 mdz: also ogra's idea about working on multimedia packages appeals to me...
09:27 slomo_     for example i maybe could help seb128 with the transition to gst 0.10 later
                 if he wants it... so if there is some work to be done in this area i would
                 gladly help out
09:28 mdz        slomo_: have you seen
                 [12] ?
09:28 mdz        I would like to hear your ideas about how we could provide the best
                 unencumbered video playback capability in the default install
                 mdz: not yet, but i know that problem but haven't thought about a
09:29 slomo_     appropriate solution for it yet... but a/v sync problems should become
                 better with gst 0.10 afaik
09:30 seb128     slomo_: are you interested by splitting xine for this? :)
                 slomo_: We don't have a terribly good reputation as a multimedia
09:31 mjg59      distribution at the moment. Given the constraints we have (patents, free
                 software) how do you see us changing that?
09:31 slomo_     seb128: why not? but what exactly needs to be split off? well, let's talk
                 about this later
09:31 mdz        slomo_: he's talking about the video-playback spec I referred to earlier
                 slomo_: do you have some ideas for any feature goals you would be
09:32 mdz        interested in working on during the Dapper cycle, either something already
                 in the spec tracker or an idea of your own?
                 slomo_: the "Split xine such that only the Xiph codecs (and perhaps
09:32 seb128     additional, unencumbered ones) are supported in main, the others will be
                 shipped in universe" of the spec
                 mjg59: in regards to patents we currently support the most formats we are
09:33 slomo_     allowed to... improving on them would imho be the only way to get better.
                 and these are most problems i heard people had with ubuntu.... i.e. they
                 can't play their dvds out of the box
09:33 mjg59      slomo_: Do you think we can do a better job of making it clear why they
09:33 slomo_     mdz: mostly the avahi goal but this is obviously completly unrelated to
                 everything i talked about yet
09:34 slomo_     seb128: sure, i could try splitting it that way
09:34 seb128     would be nice :)
09:34 seb128     thanks!
09:34 slomo_     mjg59: only by writing more documentation... i see no other way. but
                 currently the wiki already includes all this informations so no idea :/
                 slomo_: At the moment, I think we're integrating the technical side of
09:35 mjg59      multimedia into the distribution fairly well, but the social side is less
                 mjg59: yes but except doing more documentation, maybe writing a "multimedia
09:36 slomo_     guide" or something similar i see no way to let the people know why we
                 can't support for example dvd playback out of the box
09:37 mjg59      It would be good to think about ways we can improve that in the
                 distribution, rather than just referring people to the wiki
09:37 Burgwork   totem/rb needs to be able to tell people what specific codec they need
09:37 mjg59      The totem user experience in Ubuntu is currently fairly dire
                 slomo_: on your wiki page you mention that you find FreeBSD to be a
09:37 mdz        superior server platform.  can you elaborate on this, and suggest specific
                 improvements which could make Ubuntu a more natural choice for servers?
                 and for general improving of playback of all kinds of formats i think we
09:38 slomo_     should try to get more tests done... some of the issues which showed up
                 after release like the dvd playback problem caused by gst-ffmpeg would be
                 detected much earlier and could be tried to fix
09:38 slomo_     mjg59: yes, i know nobody who uses totem atm because it's too unstable for
                 them :( that needs to be improved somehow
09:39 mdz        I use totem and have not found it unstable
09:40 Burgwork   slomo, is that something we can push on to the laptop testing team? They
                 already have the hardware
=== gauss [] has joined #ubuntu-meeting
                 mdz: i think ubuntu is on the best way to be better on the server side. i
                 started using freebsd on servers already some time ago and the biggest
09:40 slomo_     advantage i saw was that you had a main system which is perfectly
                 integerated and almost bug free... but imho the same already applies to
                 ubuntu now... in fact i'm already using ubuntu on one server now
09:41 slomo_     mdz: it's mostly the applet or when playing wmv/quicktime... for "normal"
                 formats it works well... normal beeing xvid, theora, vorbis, etc
09:42 mdz        slomo_: what do you think we could do to better test multimedia support as
                 you propose?
                 mdz: get a bunch of people who regurlary test popular and unpopular
09:44 slomo_     formats... and report their problems ;) maybe make a list of formats we can
                 play and check if it works regularly
=== doko_ [] has joined #ubuntu-meeting
09:45 ogra       slomo_, volunteering to make a testplan ? ;)
09:45 dholbach   ogra: add it to: [13] :)
09:45 ogra       hehe
09:46 ogra       dholbach, only if he says he does ;)
09:46 slomo_     ogra: sure... i think i can try to get something reasonable done soon :)
09:46 ajmitch_   ogra: why? just volunteer him for it
09:47 ogra       ajmitch_, i'm the evil recruiter, but not *that* evil :)
                 slomo_: what I would suggest is to extend
09:47 mdz        [14] to include a
                 simple multimedia test in the test plan
09:47 ajmitch_   ogra: go on, take the next step ;)
09:47 mdz        slomo_: perhaps you could work with dholbach on this
09:47 dholbach   i'm happy to
09:48 slomo_     mdz: sure... sounds good :)
                 slomo_: and also to help with
09:48 mdz        [15] to ensure
                 that we have a good test video stream in the default install to facilitate
09:48 mdz        mjg59: do you have any further questions you'd like to ask?
09:48 mdz        if not, I'm ready to call a vote
09:49 mjg59      I think I'm done
09:50 mdz        ok, votes?
09:50 ogra       +1 (if i could)
09:50 mdz        ogra: please leave the voting to the board
09:51 mjg59      I think +1, based on the discussion of a testing regime and thinking about
                 improving the entire user experience
09:51 mdz        +1 from me based on positive feedback from the development team and the
                 potential for solid contributions to main
=== dholbach hugs slomo
09:52 mdz        slomo_: congratulations, thanks and welcome
=== ogra applauds
=== slomo_ hugs dholbach :)
09:52 ajmitch_   well done slomo_
09:52 slomo_     thanks everybody :)
09:52 dholbach   EXCELLENT
=== pitti ^5 slomo, welcome to the main team!
09:52 seb128     slomo_: congrats
=== \sh hugs slomo and congrats him :)
09:52 seb128     slomo_: I'll ping you for gst0.10 so :)
09:52 \sh        I read correctly: only two votes? was it the first time that a main dev had
                 only two votes?
09:52 mdz        \sh: no, we have many times had 2/3 votes
09:52 dholbach   slomo_: now if i might invite you to #ubuntu-desktop, we have some things
                 to discuss ... :-p (seb: we have him)
09:53 mdz        but today we have only 2/4 present and 2/2 votes
09:53 \sh        mdz: oh ok :)
09:53 sistpoty   congrats slomo
09:53 \sh        dholbach: don't take him away from the motu...
09:53 mdz        janimo: you proposed yourself for core-dev during the meeting; did you
                 intend to apply during this meeting or for the next one?
09:53 slomo_     dholbach: sure, but i don't have that much time today anymore ;) need to do
                 some university stuff now... only made a break for the meeting now ;)
09:53 slomo_     \sh: don't worry :)
09:53 janimo     mdz, no hurry, as long as xfce is still in universe
09:53 janimo     next time is fine
09:54 mdz        janimo: since we've been here an hour already and have more agenda already,
                 if you don't mind waiting, I think that would be better
09:54 janimo     ok, np
09:54 mdz        we seem to have 3 new MOTU candidates since the last meeting
09:55 dholbach   mako :)
09:55 mdz        zakame doesn't seem to be here
09:55 mdz        mako: ping
09:55 mdz        bojan doesn't seem to be here
09:55 ajmitch_   sadly, since zakame has been doing a fair bit of work lately with merges
09:55 \sh        hmmm...
09:55 mdz        mjg59: I'm comfortable considering mako in absentia if you are, since we
                 know him quite well already
09:56 dholbach   what happened to bmonty?
09:56 \sh        bmonty can't be here again.....but I would like to propose a vote in
09:56 mjg59      Yup
09:56 \sh        because bmonty did now a great work during the merge etc. and I really like
                 to see him in the team.
09:56 mdz        +1 from me for mako, no-brainer based on past contributions to both Debian
                 and Ubuntu
09:56 mjg59      +1 for mako, too
09:57 mdz        done and done
09:57 ajmitch_   that was a quick appointment :)
09:57 \sh        mako: do some merges asap :)
09:57 Seveas     wow, fastest ever I guess :)
09:57 ogra       yes, bmonty was postponed several times ...
09:57 dholbach   \sh: i watched his work too, and i was impressed, by how much bmonty did
                 during those merges
=== tseng [] has joined #ubuntu-meeting
09:58 mdz        mako has been contributing to Ubuntu since its inception and has only now
                 decided to apply officially ;-)
09:58 \sh        dholbach: yes .. I did some uploads for him the last days...and I'm
09:58 ogra       and prepares uploads all the time for us ... its a bit sad
09:59 sistpoty   yes... the few packages of bmonty i came to look over showed good
                 packageing skills. and he did _lots_ of work
09:59 slomo_     bmonty would also get a vote by me... he does _SO_ many merges lately we
                 almost can't keep up with uploading his stuff
10:00 sistpoty   and he interacts with debian (files bug w. patches in BTS for stuff he
10:00 mdz        is he mostly doing trivial merges from MOM or more in-depth merging as
10:01 \sh        mdz: both
10:02 mdz        ok
10:02 \sh        mdz: most of universe is trivial only one out of 50 is really non trivial
10:02 \sh        (forgetting the gstreamer universe packages of slomo)
10:03 mdz        mjg59: any questions regarding bmonty?
=== sistpoty counts 24 dapper changes mails from bmonty
10:03 \sh        sistpoty: and some syncs he couldn't request
10:03 mjg59      mdz: Don't think so - motu reports sound good
10:04 mdz        yes, while he isn't present there are several people here willing to
                 provide testimonials
10:04 \sh        sistpoty: and not all of his reports are uploaded actually
10:04 mdz        votes?
10:04 ogra       he was really patient with being postponed from meeting to meeting ...
10:04 mjg59      +1 from me
10:04 mdz        +1 from me based on testimonials from several regular MOTU contributors and
                 reviewers, both at this meeting and previous ones
10:04 dholbach   cool :)
10:04 ajmitch_   we'll inform him of the good news then
10:04 mdz        dholbach: will you pass on the news to him personally?
10:04 sistpoty   \sh: very true... we need to sponsor more uploads. I think I'll go for this
                 tonight... -> motu after meeting
10:04 ogra       welcome bmonty in absentia !
10:05 dholbach   mdz: i will
10:05 \sh        mjg59 / mdz: thanks :)
10:05 mdz        dholbach: thanks, send my congratulations
10:05 dholbach   mdz: as personally, as internet lets me :)
10:05 \sh        dholbach: blog it :)
10:05 dholbach   we don't have a MOTUPhoneNumber page yet :)
10:05 \sh        dholbach: I know he is reading the planet :)
10:05 \sh        +49 700 sourcecode? ,-)
10:05 mdz        there are 18 pending applications in launchpad right now
10:05 Seveas     Dial M for MOTU ;)
10:06 \sh        or should I get +49 700 motu ?
10:06 mdz        ogra,dholbach: would you ping each of them and confirm that they still
                 intend to apply and will attend a meeting?  we need to clean out that list
10:06 ogra       mdz, 90% of them i've never heard of
10:06 dholbach   mdz: i know 3 of those missing ones
10:06 ogra       or seen them on irc
10:06 dholbach   mdz: that's sivang, vuntz and zakame
10:06 mdz        if you've never heard of them, they should receive a form letter explaining
                 how the process works
10:06 pitti      btw, what about cleaning up members which are inactive? like astaroth?
10:07 ogra       most of them dont even have a wikipage
10:07 dholbach   mdz: i will take care of that
10:07 mdz        dholbach: thank you very much
10:07 dholbach   de rien
10:07 ajmitch_   pitti: I think maintainership was meant to have a year or 2 year term,
10:07 pitti      ajmitch_: ah, ok
10:07 mdz        pitti: what is astaroth's real name?
10:07 pitti      mdz: Gerardo di Giacomo
10:08 pitti      mdz: the guy who helped with universe security updates until he became a
10:08 pitti      it's by no way urgent to remove him, this example just came into my mind
10:08 mdz        pitti: please ping him and see if he intends to contribute in the future
10:08 pitti      yes, will do
10:08 dholbach   same for some other folks
10:08 mdz        pitti: we should not generally deactivate anyone simply because they go
                 inactive; we have the expiration process for that
=== zakame [n=zak@ubuntu/member/zakame] has joined #ubuntu-meeting
10:09 zakame     hi all
10:09 ajmitch_   hi zakame
10:09 \sh        dholbach: we should discuss how we should proceed with this "problem"
                 \sh: it's hard to decide... pinging back is the only thing, i can think of
10:09 dholbach   - there are times in life, where you simply don't have the time or drive to
                 do it
                 \sh: a reasonable approach is to contact them and ask their intentions.  if
10:09 mdz        they say that they can't or won't contribute anymore, they can voluntarily
                 deactivate themselves in launchpad
10:10 mdz        \sh: and if they don't respond, they will eventually expire
10:10 \sh        mdz: the expiration process is already working :)
10:10 mdz        zakame: just in time
10:10 zakame     mdz: thank you :)
10:11 ajmitch_   mdz: will we have to undergo another interrogation around expiry time? :)
10:11 mdz        dholbach: you mentioned that you had some experience working with zakame?
10:12 mdz        ajmitch_: we have some time to finalize that part of the process ;-)
10:12 ogra       zakame, nice wikipage :)
10:12 zakame     ogra: many thanks :)
10:12 dholbach   mdz: that i "knew him" and watched his progress - he's been fairly busy in
                 the mergers crew and iirc did some std allocator changes as well
10:13 dholbach   mdz: i have 217 bug mails from him, mostly merges, some bug triaging work
                 as well
10:13 zakame     just a couple for c2a i think... libcommoncpp2 was already done in debian,
                 and my most recent one was for MAS
10:14 dholbach   i'm not too familiar with his work, but what he said in #ubuntu-motu
                 usually was sound
10:15 ogra       zakame, you dont mention that you help in edubuntu too on your wiki ....
10:15 sistpoty   though I haven't reviewed much of his work, I'm impressed by zakame's
                 amount of work...
10:15 \sh        oh yes..zakame is just hard working like bmonty or ajmitch, slomo,
                 siretart, sistpoty or my person.
                 zakame: I happened to notice your merge of lostirc; it looks like the only
10:15 mdz        Ubuntu-specific change had been to update to a new upstream version, which
                 is now in Debian.  why was this a merge rather than a sync?
10:15 \sh        I had a view over his work, and his debdiffs were very good, for the time
                 he's doing motu work. I'm happy to have him in the team
10:17 zakame     mdz: hm, you're right, this seems to just update aclocal.m4, and yes, S-V
                 :(  my bad!
10:17 \sh        mdz: beginners luck I would name it...because I'm the one who has
                 "beginners luck" all the time...;)
10:18 zakame     ogra: Ooh!  I forgot that part!  very sorry!!!
10:18 ogra       mdz, zakame expressed interest to help in edubuntu ...
10:18 mdz        zakame: please be careful with that in the future; each package which is
                 diverged creates more work for the team
10:19 ogra       zakame, was it doc or dev ?
10:19 zakame     mdz: yes, I'll keep that in mind
10:21 mdz        zakame: who sponsors your uploads to Ubuntu usually?
                 ogra: hm, I'm collaborating with some teachers at the local school to
10:23 zakame     implement an edubuntu system... we currently are running hoary, but I
                 managed to get hold of edubuntu yesterday, so we'll be trying to upgrade
                 maybe this afternoon
10:23 ogra       cool
10:24 \sh        mdz: nafallo and I
10:24 zakame     mdz: Nafallo_away did most of the sponsoring, though most recently \sh
                 sponsored logilab-common and another...
                 zakame: we'll take a look for the others...actually I was busy merging
10:25 \sh        during the I have to find the time to get all pending uploads
                 done from malone
10:25 mdz        mjg59: anything else before voting?
10:25 mjg59      Don't tihnk so
10:25 zakame     \sh: thanks again :) most of them are PendingSync
10:25 mdz        likewise
10:26 mdz        +1 based on my own examination of various uploads, testimonials from MOTU
                 and discussion
10:26 \sh        zakame: if you can provide me a list of malone numbers :) that would be
                 great :)
10:26 mjg59      +1 based on the MOTU opinions
10:26 ogra       \sh, see wikipage :)
10:26 mdz        zakame: welcome aboard
=== dholbach hugs zakame
10:26 dholbach   that's brilliant news :)
10:26 sistpoty   congrats zakame
10:26 ogra       yay, welcome zakame
10:26 minghua    zakame: congratulations. :-)
10:26 \sh        zakame: welcome aboard :) good shot :)
10:26 slomo_     zakame: congrats :)
10:27 mdz        pitti: you wanted to discuss something regarding sudo?
10:27 pitti      right
10:27 ajmitch_   zakame: well done
10:27 zakame     yay!
=== zakame hugs everybody :D
10:27 pitti      [16]
10:27 pitti      ^ for reference
10:27 zakame     many thanks all! :)
10:27 pitti      there was not much fruitful discussion
10:27 mdz        right, this thread is long and I haven't had a chance to read it yet
10:27 pitti      the problem is in short:
10:28 pitti      initially we wanted to use sudo -t command to check whether an user can
                 execute command
10:28 \sh        zakame: cool page :) I'll work with the information from this page
10:28 zakame     \sh: thanks
10:28 pitti      if that would log auth failures, then it would remain compatible with
                 default sudo behaviour on servers and not circumvent security checks
10:28 mdz        pitti: I think extending sudo to parse the .desktop file adds undesirable
                 complexity to a setuid root program
10:29 pitti      mdz: I only see two options TBH: parse .desktop files in sudo or fall back
                 to the broken group check
10:29 pitti      mdz: parsing .desktop files would nicely solve the desktop/server conflict
10:29 pitti      on servers there won't be .desktop files, so that sudo checks are not
10:29 pitti      and on desktops we would avoid the log clutter from failed checks
10:30 mdz        pitti: it would certainly be nice to avoid execing sudo so many times
                 during every login
10:30 pitti      mdz: well, we need to execute it once for every desktop file that wants
10:30 mjg59      pitti: The sudo -t case would presumably also result in error mails every
                 time someone logs in?
10:30 pitti      i. e. maybe 15 times for a normal system per login
10:30 ogra       how would that cope with the gnome speeup plans ?
10:30 ogra       *speedup
10:30 pitti      mjg59: right, that's the most annoying thing right now
10:31 mjg59      Why are we trying to achieve this?
10:31 mdz        mjg59: in order to simplify the menus for unprivileged users
10:31 pitti      mjg59: we want to hide admin tools from the menu for users who aren't
10:31 mdz        i.e., don't show them administrative tools requiring sudo if they won't be
                 able to use them
10:31 pitti      [17]
10:31 mjg59      Surely a common use case is that an admin will wish to debug things while a
                 user is logged in?
10:31 mdz        mjg59: the menu items have no chance of working unless the user has sudo
10:31 Mithrandir pitti: can't we write a helper which is suid root and parses the desktop
                 files and asks sudo "can this user run this command"?
10:31 mjg59      Hrm. True.
10:31 pitti      mjg59: 'run program as another user'
10:32 ogra       and the worst thing is that they just silently fail
10:32 pitti      Mithrandir: what would that solve?
10:32 pitti      Mithrandir: sudo would still log violations
10:32 Mithrandir pitti: it would not put the desktop parsing code in sudo.
10:32 pitti      Mithrandir: and doing the check in sudo is safer than writing a new program
                 from scratch
10:32 mjg59      ogra: I think the silent failure is a bug in itself, but still...
10:32 ogra       yup
10:32 mdz        Mithrandir: that code would still run as root, though
10:32 Mithrandir mdz: yes, but it would be easier to merge from debian that way.
10:33 pitti      I mean, parsing is not terribly difficult
10:33 pitti      but of course it must be done carefully
10:33 mjg59      But surely this inevitably subverts part of sudo's security?
10:33 Mithrandir pitti: I just don't see upstream wanting to incorporate that patch, without
                 knowing sudo upstream.
10:33 mdz        pitti: is there a program which is run whenever a new .desktop file is
10:33 pitti      mjg59: to the extent that an intruder can check commands mentioned in
                 installed (root owned) desktop files
                 pitti: one approach would be to have such a program dump a list of all of
10:33 mdz        the relevant commands to a (trusted) file and have sudo suppress its error
                 reporting for any command listed exactly in that file
10:33 pitti      mjg59: but on desktops we can safely forget about logging anyway
10:34 mjg59      pitti: Which, in a standard ubuntu install, amounts to everything
10:34 pitti      mdz: dpkg install hooks? (SCNR)
10:34 mvo        there is dh_desktop
10:34 pitti      mjg59: why everything?
10:34 pitti      mjg59: on a server there won't be any/many desktop files
10:34 mjg59      pitti: If a user has sudo rights to execute admin tools, they have sudo
                 rights to execute anything
10:34 pitti      and seriously, whoever runs sudo under X doesn't need to care about the
10:35 pitti      mjg59: under X at least (event injection, etc.)
                 pitti: what does a hypothetical attacker gain by being able to test for
10:35 mdz        sudo rights in this way?  any attempt to use those rights is more closely
10:35 pitti      mjg59: but the case I worry about is to not impede server security checks
                 To be honest, I'm fairly strongly of the opinion that we should just accept
10:35 mjg59      that we made a mistake in Warty, cut our losses and just display them for
                 users in the admin group and otherwise not do so
10:35 mdz        pitti: for the common case, any unprivileged user on the system can already
                 check for membership in the admin group
10:35 pitti      mdz: he can silently poke around to check which privileges a cracked user
                 account has
10:36 pitti      mdz: right now, sudo immediately mails out failures to the admin
10:36 mjg59      Rather than produce a complex solution that provides extra information
                 leakage about what rights a user has
10:36 pitti      mdz: so that the admin can quickly close the user account, etc.
10:36 mdz        mjg59: if we do that, we need to heuristically add users to the admin group
                 on upgrades
10:36 pitti      mjg59: but that's not just a warty upgrade issue
10:36 mjg59      mdz: No, we can document it in the release notes
10:36 mdz        pitti: they can already do that silently with 'groups'
10:36 pitti      sudo is more flexible than just crude admin/no admin
10:36 mjg59      "Admin applications will only be visible to users in the admin group"
10:37 dholbach   sorry, i'll leave now, because i'm dead tired - good night
10:37 mjg59      pitti: Yes, but it's not the sudo case that we care about really
10:37 ogra       bye dholbach
10:37 mdz        mjg59: we don't display the release notes on upgrades yet
10:37 zakame     bye dholbach :)
10:37 pitti      mjg59: well, the question is if we do...
10:37 mjg59      What we care about is "should this user see these icons"
10:37 pitti      I don't see why we should force admins to use the admin group
10:37 mjg59      pitti: Because it's the existing mechanism for flagging user capabilities
10:37 mdz        pitti: I don't think we should; I'm just pointing out that we already make
                 most of this information available by using the admin group the way wedo
10:38 pitti      mdz: not on my server :) I use /etc/suders to directly configure allowed
                 commands for users, not via groups
10:38 mjg59      In the brave new world of selinux, the obvious thing to do would be to have
                 admin users have an selinux capability
10:38 pitti      mdz: I agree, when the admin group is used, the case is trivial
10:38 ajmitch_   that brave new world won't be on by default in dapper
10:38 mdz        and that is our default configuration for Ubuntu
10:38 Mithrandir mjg59: what would we do in the cases of people being allowed to do some
                 things as root, but not all?
10:39 ogra       mdz, not for warty upgraded systems
                 Limiting visiblity to people in the admin group fixes the vast majority of
10:39 mjg59      cases that we're worried about, and doesn't involve us developing what is,
                 effectively, a new authentication mechanism
10:39 mdz        ogra: that is missing the point
10:39 ogra       mdz, that will be a good bunch of users ....
10:39 pitti      mjg59: but that makes the usage of non-group sudo impossible
10:39 janimo     checking sudo -t only once and then using a blacklist of apps which are not
                 to be shown? would that not scale?
10:39 mjg59      pitti: No it doesn't
10:39 pitti      mjg59: since then the users would never see the desktop files
10:40 mjg59      pitti: The apps can be run from a shell
10:40 mdz        ogra: the only reason not to use sudo for this is that it reveals
10:40 pitti      mjg59: right, of course
10:40 pitti      I mean in terms of correct menus
10:40 mjg59      pitti: They can launch a shell, add themselves to the admin group and then
10:40 mdz        ogra: but that is only the case if the user has extensively customized the
                 system, since our default configuration and tools reveal it already
10:40 pitti      mjg59: erm?
10:41 mdz        janimo: what would the blacklist contain?
=== mgalvin [] has joined #ubuntu-meeting
10:41 pitti      mjg59: if I allow an user to run only a particular command as root, he
10:41 pitti      janimo: that doesn't react to changes
10:41 janimo     the apps which are to be run only as sudo
10:41 mjg59      pitti: Are you suggesting that certain users should have access to specific
                 admin tools, but not all?
10:41 janimo     changes as in introducing new packages?
10:41 pitti      janimo: we already know this, it's in the desktop files
10:41 mjg59      pitti: Making icon visibility depend on being in the admin group doesn't
                 mean that the admin group must have full sudo rights
10:41 ogra       mdz, my initail reaction was the same as yours, but Kamion made some valid
                 points i cant remember currently ... sad he isnt here
10:41 pitti      mjg59: why not? I could allow an user to set the time, but nothing else
10:42 mjg59      pitti: It's an insanely tiny use-case
10:42 pitti      well, ok, if we say that we basically ignore /etc/sudoers and jsut support
                 admin group, that's fine for me
10:42 mdz        mjg59: we don't need to account for it in our defaults, but we should avoid
                 making it impossible if w ecan
10:42 pitti      I just want to have that decision formally settled
10:43 mjg59      mdz: It would still be possible by changing the semantics of the admin
                 group on that system
10:43 mdz        mjg59: how do you mean?
10:43 mjg59      mdz: Don't give admin users sudo rights
10:43 pitti      mjg59: no, you need several groups then, which we don't suport
10:43 pitti      mjg59: well, we could have a mapping somewhere
10:43 mjg59      pitti: We don't support it how?
10:43 pitti      group -> desktop files
10:44 mdz        mjg59: hmm
10:44 mjg59      I mean, you /could/ solve this just by having the desktop files be 640,
10:44 pitti      mjg59: i. e. the menu only reflects admin membership, not the actual
                 privileges an user ahs
10:44 pitti      has, even
10:44 mjg59      Or just using ACLs
10:44 pitti      mjg59: sure, but who configures that?
10:44 mjg59      pitti: The admin
10:45 pitti      dpkg-statoverride? well, that would work
10:45 mjg59      I'm sorry, I feel like I must be missing something really obvious here
10:45 pitti      but it certainly needs a guy
10:45 pitti      gui, even
10:45 mdz        mjg59: we have some conflicting goals
10:45 mdz        we would like to hide the entries where the user can't possibly make use of
10:45 pitti      our current sudo supports sudo -t command
10:45 mdz        but we want to avoid hiding them if the user can use them
10:45 pitti      but that generates clutter on desktops
10:46 pitti      so we need to test at a higher level
10:46 Mithrandir pitti: can we just get sudo -t to log, but not mail?  I think that would be
10:46 mjg59      mdz: But that goal inherently provides information leakage about user
10:46 mdz        we implemented a solution as pitti describes which makes it trivial to
                 query sudo for this information
10:46 pitti      Mithrandir: then we don't need mail for sudo without -t either
10:46 mdz        mjg59: yes, in my opinion a certain amount of leakage is probably OKO
10:46 mdz        OK
10:46 pitti      Mithrandir: which would change sudo semantics on servers, too
10:46 pitti      Mithrandir: sudo -t command && sudo command
10:46 Mithrandir pitti: hmm, right.
10:47 mjg59      mdz: I worry about changing security expectations from traditional unix
10:47 pitti      mjg59: right, the question is how much leakage we want to sacrifice for
                 this hide-admin spec
10:47 mdz        pitti: hmm?
10:47 ogra       cant you add a switch to sudo for mailing the admin can set ?
10:47 mdz        mjg59: I think sudo is a bit young to have traditional security
10:47 ogra       i.e. have it off by default on desktops and on on servers ?
10:47 mdz        and this problem only applies to sudo
10:47 pitti      ogra: sure, but I doubt that it would be easier than grepping desktop files
10:47 mjg59      mdz: I've seen people using it for years
10:48 pitti      ogra: what defines a server then?
10:48 \sh        sudo is not wasn't popular...just like the story about telnet and
10:48 ogra       pitti, dunno, but we build this system, we can define it ...
10:48 mdz        mjg59: I agree with you in that getting to dapper from warty requires
                 fairly extensive command-line familiarity already
10:48 pitti      ogra: the problem is, the admin defines the purpose of the install, not we
10:49 mdz        mjg59: but I think we need to do better than the release notes if we're
                 going to rely on admin membership in this way
10:49 ogra       pitti, but we can define flags that get set, based on default options the
                 installing person choose
10:49 pitti      ogra: right, that was option 2 in my email to u-d
10:49 ogra       or checks
10:49 mdz        pitti: do you think we could safely add users to the admin group on
10:49 mjg59      mdz: Well, it's possible to do that (at the cost of requiring manual
                 intervention during the upgrade)
10:50 pitti      mdz: no, I'd not do that
10:50 mdz        the entry created in sudoers by the installer is specially marked
10:50 pitti      mdz: IF the admin configured fine-grained permissions, then this would lead
                 to privilege escalation
10:50 Mithrandir mdz: we could have an upgrade tool which asked the admin how he wanted
                 stuff done, but I dislike that.
=== ajmitch_ hasn't added an admin group here, and probably would be surprised to see it on
an upgrade
10:50 mdz        pitti: I think that can be avoided
10:50 pitti      well, I wouldn't have a good feeling with changing group memberships on
                 upgrades, even less so with admin
10:50 \sh        mdz: this is somehow not the right solution...better to ask during
                 dist-upgrade "Who is your admin user?"
10:50 mdz        pitti: the process would be to check for an entry in sudoers of the form:
10:50 Mithrandir something like a ubuntu-fixup package which asked questions and tried to
                 fix stuff in the postinst.
10:50 mdz        # Added by Ubuntu installer
10:50 mdz        mdz     ALL=(ALL) ALL
10:51 pitti      mdz: we check for a default sudoers and do it only then?
10:51 mdz        pitti: a sudoers with the default entry
10:51 mdz        pitti: which is equivalent to admin group membership
10:51 mdz        i.e., unrestricted sudo to root
10:51 pitti      mdz: well, that would cover the warty upgrade, what about the general usage
                 of visudo without admin group?
10:51 pitti      i. e. finer grained privs?
10:51 mdz        pitti: wouldn't those be superseded by the ALL entry?
10:52 mdz        configuring finer-grained privileges would require removing the ALL entry
10:52 pitti      mdz: I mean with nonstandard sudoers (when we don't add users to admin)
10:52 pitti      not for upgrades
10:52 mdz        pitti: I don't understand
10:52 pitti      mdz: if I allow joe to use sudo time-admin, but nothing else, then joe
                 would not see time-admin in the menu
10:52 pitti      mdz: if we don't care about this case, then group check is sufficient
10:52 pitti      if we do, then it's not
10:52 mdz        pitti: unless you add joe to the admin group
10:52 mjg59      Does dpkg-statoverrides have support for POSIX ACLs?
10:53 mdz        mjg59: RUN AWAY
10:53 mjg59      mdz: But then he'd see all of them, not just time
10:53 mdz        mjg59: that is acceptable to me
10:53 pitti      mdz: he would not be in admin, of course, otherwise the 'sudo time-admin'
                 entry would be pointless
10:53 mdz        pitti: if the admin wants finer grained permissions, they would remove the
                 %admin entry
10:53 pitti      I know that it's a corner case
10:53 \sh        pitti: is this the normal use-case for desktop installations?
10:53 pitti      but we should clearly say whether or not we support it
10:54 pitti      \sh: no
10:54 \sh        I think I can remember windows xp asking even unprivilegded users to update
                 windows xp via windows update
                 pitti: It's something that can be supported by the admin removing the read
10:54 mjg59      bit from the desktop files, and then adding individual users to an
                 associated ACL
10:54 \sh        and the user clicks on the toaster and "u don't have rights"
10:54 ogra       \sh, remember we are better than MS
10:54 pitti      mjg59: I agree
10:55 mjg59      And I think we support ACLs on all our supported filesystems
10:55 mdz        mjg59: which ones are our supported filesystems?
10:55 ogra       heh
10:55 pitti      it's just not something a non-hardcore freak would do
10:55 mdz        mjg59: currently, the process for granting admin privileges is trivial:
                 adduser <user> admin, or check the tick box in the GUI tool
                 ogra: what I wanted to say with this is: what is the typical use case for a
10:55 \sh        desktop...single machine. and if there is a second or third account most
                 people don't care if they see the admin tools or not...if they get the
                 "sorry, not allowed" message..they don't care anymore
10:55 mjg59      mdz: Right, and I'd see that as the default
10:56 mdz        ACLs complicate that for both cases (more commands, and complicating the
10:56 mdz        mjg59: so you're suggesting that we don't try to hide these entries by
10:56 mjg59      No, we hide those entries by default
10:56 mdz        mjg59: and leave it to the admin only if they really want to configure it
                 that way?
10:56 pitti      but isn't our problem exactly the other way round?
10:56 mdz        pitti: yes
10:56 mjg59      In the corner case of an admin wanting a user to be able to run a single
                 application but not all of them, they use the ACL solution
10:56 pitti      users who aren't in admin, but have special rights won't see the desktop
10:57 pitti      instead of users without rights see them
=== seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-meeting
10:57 mjg59      mdz: ext3, xfs, jfs, reiserfs and nfs support them
                 mjg59: the ACL solution being: remove the %admin entry from sudoers, add
10:57 mdz        the more specific entries, and set ACLs on the .desktop files corresponding
                 to the more specific entries?
10:57 pitti      ah, I see, we make the desktop files root:admin 640 by default?
10:57 mjg59      mdz: Correct
=== seb128 [n=seb128@ubuntu/member/seb128] has left #ubuntu-meeting ["Ex-Chat"]
10:57 mjg59      pitti: Yeah, that would work
=== seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-meeting
10:58 mdz        mjg59: I think dpkg probably clobbers ACLs on upgrades
10:58 mjg59      mdz: Well, that's a feature request for dpkg :)
10:58 ogra       and i dont think we need even to think about this special cornercase ...
10:58 ogra       switch all on or all off ...
10:58 pitti      "Dear Keybuk, please teach dpkg-statoverride ACLs, kthxbye"?
10:59 mdz        pitti: I have an idea
10:59 pitti      give us the ultimate solution, Matt! :)
10:59 mdz        pitti: we could allow users to query sudo without any logging or warning if
                 they are in the admin group
10:59 \sh        hmmm....
10:59 mdz        pitti: and otherwise, fall back to displaying all of the menu entries
10:59 pitti      mdz: that's what happen right now
10:59 pitti      oh, wait
11:00 ogra       isnt that backwards ?
11:00 pitti      well, if they are in admin, then we already know everything
11:00 mdz        IFF they are in the admin group
11:00 pitti      we want to know information if they aren't
11:00 ogra       exactly
11:00 mdz        if they aren't, we just display everything
11:00 ogra       but we dont want this
11:00 mjg59      mdz: Uhm. No, surely?
11:00 pitti      well, then we don't need to do anything :)
11:00 mdz        I'm not particularly interested in having finer-grained menu entries
                 corresponding to finer-grained sudoers
11:00 mdz        I just don't want the functionality to disappear from the desktop
11:00 pitti      becaue that would mean to always show everything :)
11:00 mjg59      mdz: If they're not in the admin group, we don't want to display anything
11:01 mdz        mjg59: you are introducing facts into the discussion
11:01 ogra       lol
11:01 \sh        I wonder if it's possible to create a patch which is doing the query if a
                 user is in admin group or not inside of the menu display
11:01 mjg59      Simplest solution:
11:01 mjg59      1) Make .desktop files 640 and group admin owned
11:01 pitti      \sh: that's easy, yes
11:02 mjg59      2) Transition default user to admin group for warty upgrades
11:02 mjg59      Result: Most use cases sorted
11:02 mdz        mjg59: 2) is scary
11:02 pitti      I have a bad feeling about 2)
11:02 ogra       mjg59, how do we know its a warty upgrade ?
11:02 \sh        pitti: and the gnome-menu reads the desktop file, right?
11:02 pitti      but I like 1)
11:02 mjg59      We're talking about users who, in sudoers, have ALL=(ALL), right?
11:02 pitti      \sh: right
11:02 mdz        mjg59: we don't have a persistent record of who the default user is and
                 whether it's been customized
11:02 mjg59      So they could add themselves to the admin group *anyway*
11:02 pitti      right
11:03 ogra       mjg59, yes, but i might have set this in a brandnew breezy because i think
                 its cool
11:03 mdz        mjg59: it seems probable that there are corner cases
11:03 ogra       so we would break hat
11:03 ogra       that*
11:03 pitti      I'm not questioning that, but we have to make damn sure that we get that
11:03 mdz        what happens when you have multiple matching entries in sudoers for a user?
11:03 mjg59      mdz: If they have a fine-grained setup, we do nothing
                 pitti: so..when we set a special "X-Admin: true/false" inside of the admin
11:04 \sh        apps and checking in gnome-menu if or if not the user a) is in admin group
                 or not and b) if the app which is described in .desktop is admin tool or
                 not..and then display or not display it
11:04 mdz        mjg59: meaning what?  we don't touch it unless it hasn't been modified
                 since installation?
11:04 pitti      \sh: see the spec, yes
11:04 mdz        mjg59: I'm saying that I think sudoers semantics may allow a finer-grained
                 setup without removing the default entry
11:04 mjg59      mdz: I think we can justifiably add any user who has privileges to run
                 anything to the admin group
11:05 pitti      mjg59: your chmod solution has the added benefit that we don't actually
                 need to add that X-Requires-Root: true key :)
11:05 Mithrandir mjg59: that's not problematic, I think giving the admin group
                 root-equivalent priviledges might be more problematic.
=== ogra still wonders why we solve a GUI problem in the backend, and not in the GUI
11:05 \sh        ogra: you can read my mind?
11:05 mdz        mjg59: I'm saying that that situation is difficult to detect reliably; it
                 may not be as simple as looking for the expected line in sudoers
11:05 mdz        mjg59: and the risks of being too liberal are pretty severe
11:05 ogra       its a task for gnome-menus as it was thought out in the beginning imho
11:05 pitti      ogra: how do you want to determine if user foo can execute sudo command?
11:06 ogra       pitti, if i check his groups
11:06 pitti      mdz: if we go for group checking, then I'd prefer a release note
11:06 \sh        pitti: sudo should be excuted by anyone...the app to run afterwards is
                 determined by sudoers...we still have the cli
11:06 mdz        pitti: I fear that we will be flooded by reports of users upgrading and
                 then being locked out
11:06 pitti      not doing a relative simple .desktop parsing for security reasons, and then
                 add a highly delicate sudoers rewriting doesn't fit together
11:06 ogra       i wouldnt touch sudo at all ...
11:07 mdz        pitti: we don't know how many breezy systems are out there which are
                 upgrades from hoary and warty
11:07 mjg59      The current options have at least one of the following problems:
=== lamont [] has joined #ubuntu-meeting
11:07 mjg59      a) Increase information leakage
11:07 pitti      ogra: well, but see backlog, not every sudoer is in admin group
11:07 mjg59      b) Increase code run as root
11:07 mjg59      c) Are awkward for upgrades
11:07 mdz        we've already increased the information leakage
11:07 mjg59      mdz: How?
11:07 ogra       pitti, corner cases ...
11:07 pitti      with the admin group
11:08 mdz        mjg59: sudo -t no longer asks for a password
11:08 mjg59      mdz: I think that's a bug
11:08 mdz        mjg59: it just bitches in the log
11:08 \sh        pitti: but during a dist-upgrade from warthy, hoary, breezy to dapper, we
                 could ask questions...and we can "rearrange /etc/sudoers"
11:08 pitti      mdz: how is that information disclosure?
11:08 mdz        pitti: for the same reasons we've been discussing all along
11:09 ogra       why not focus on the group and make a note in the release notes ... to
                 warty systems it simply wont make a difference ...
11:09 pitti      mdz: I don't understand why sudo -t command without a password discloses
11:09 mdz        pitti: it allows the user (or an attacker with their privileges) to query
11:09 pitti      mdz: right, but not unnoticed
                 mdz: Unless the default behaviour of sudo -t failing is identical to the
11:09 mjg59      default behaviour of attempting to execute a command without privileges (in
                 terms of admin notification), I think that's incorrect
11:09 mdz        pitti: the information is still leaked, we just record the fact that it was
11:10 mjg59      When was this -t behaviour changed?
11:10 mdz        dapper
11:10 mjg59      Right. So we can revert it.
=== amu [i=amu@debian/developer/amu] has joined #ubuntu-meeting
11:10 mjg59      mdz: It's the sort of thing that will get mentioned on bugtraq
11:10 mdz        if we can't do this without unacceptable tradeoffs in robustness or
                 security, we should consider not doing it
11:10 mdz        mjg59: I do not fear bugtraq
11:10 pitti      mdz: right
11:11 mjg59      mdz: I don't fear bugtraq. I fear negative PR associated with "Ubuntu
                 change security tool default behaviour to one that leaks more information"
11:11 mdz        I believe it was also mentioned on bugtraq that we grant sudo privileges
                 rather than using a root password
11:11 amu        moin
11:11 mdz        the world moved on
11:11 ajmitch_   hi amu
11:11 ogra       hey amu
11:12 pitti      ok, then let's ignore the custom sudoers case and just check for admin
11:12 ogra       yeah
11:12 mdz        pitti: that leaves us back to dealing with warty upgrades
11:12 pitti      the workaround is really evil, but it seems that sudo solution is evil, too
11:12 ogra       for warty upgraded systems the menu will just go on looking like before ...
11:12 mjg59      mdz: If sudo -t continues to log, then that's going to be a *lot* of log
                 entries for terminal server-type installs
11:12 mdz        and hoary, in fact, no? didn't we change to group admin in breezy?
11:12 mjg59      And if it doesn't log, it's a security pain
11:12 ogra       i dont think thats bad
11:12 mjg59      I /think/ hoary had an admin gorup
11:12 pitti      mjg59: it should log
11:13 mdz        mjg59: it's unacceptable to use sudo for this if it logs
11:13 pitti      mjg59: hoary had
11:13 mdz        mjg59: but you've said that you find it unacceptable to use sudo for this
                 at all, already
11:13 mdz        because we can't use sudo for the query unless we allow it to be queried
                 without a password
                 mdz: I think it's bad to use sudo in a way that leaks information. I think
11:13 mjg59      it's /terrible/ to use sudo in a way that doesn't log if an unauthorised
                 user runs it.
                 I'm all for using the admin group check IFF we can find a  way to fall back
11:14 mdz        gracefully for systems which never had that configuration in the first
11:14 pitti      mjg59: well, with the desktop file test, we would not leak any info on
11:14 mdz        do we create the admin group on upgrades?  if not, we could check for its
11:15 ogra       no, we dont
11:15 pitti      we would drop -t
11:15 pitti      and introduce --check-desktop-file, or so
11:15 mjg59      pitti: Uhm.
11:15 mjg59      pitti: How does that help?
11:15 ogra       why must that be done on sudo pitti ?
11:15 ogra       in*
11:15 pitti      mjg59: on servers there are no .desktop files, so there is no information
11:15 mdz        ogra: are you sure?  where is admin created?
11:15 mjg59      pitti: That's not a sensible assertion
11:15 pitti      ogra: /etc/sudoers is readable only by root
11:16 ogra       mdz, from hoary on in the installer afaik
11:16 mjg59      pitti: mjg59@kern:~/ > locate .desktop | grep /usr | wc 353     353   16080
11:16 ogra       pitti, we have the info in the .desktop files, we can make gnome-menus
                 check the group
11:16 mjg59      mjg59@kern:~/ > wc /etc/passwd
11:16 mjg59        3576   8484 220748 /etc/passwd
11:16 ogra       no need to touch sudo at all
11:16 mjg59      pitti: So, no. Being a server does not mean that people don't run graphical
11:17 pitti      mjg59: well, we would limit the information leak to exactly the information
                 we need  - desktop files
11:17 pitti      instead of arbitrary commands
11:17 pitti      mjg59: well, if people use sudo under X, then we don't need to worry about
                 information leaks
11:17 mjg59      pitti: But the user then (effectively) knows that they can execute whatever
                 is in that .desktop file
11:17 mdz        ogra: I can't find where it's created
11:17 pitti      mjg59: exactly
11:17 pitti      that's the amount of sacrifice we need to do IF we want this
11:17 ogra       mdz, i only know that its there since hoary ... for all new installs i did
11:18 mjg59      pitti: Right. So I think it's a stupid idea in that form.
11:18 ogra       mdz, and its not there on upgraded systems
11:18 pitti      mjg59: it's better than sudo -t command IMHO
=== pusakat [i=proxy@] has joined #ubuntu-meeting
11:18 mjg59      pitti: Being stabbed in the hand is better than being stabbed in the eye :)
11:18 sistpoty   why not check in /etc/group as heuristic instead of the sudoer-file?
11:18 pitti      *shrug*
11:18 mdz        pitti: how about my suggestion?
11:19 pitti      mdz: the one with not doing anything at all?
11:19 mdz        pitti: if the admin group exists, use it to test whether to display the
                 menu entries.  if it doesn't exist, display them all.
11:19 pitti      mdz: that's what we have now
11:19 ogra       mdz++
11:19 mjg59      That works for me.
11:19 pitti      oh, ok
11:19 mdz        pitti: and revert the sudo change
11:19 pitti      mdz: would work for me
11:19 ogra       the behavior for upgraded warts just wont change ...
11:19 mdz        I thought we created admin on upgrades, but ogra pointed out that this
                 isn't true
11:19 mdz        so this is a very simple solution
11:19 pitti      for warty upgrades that's certainly fine
11:20 pitti      people are used to the menus by now, probably
11:20 mdz        ok, I think we've licked it
11:21 ogra       so keep the change at gui level ?
11:21 mdz        that only took an hour
11:21 pitti      mdz: that would mean to break the case when admin group is not actually
                 used, but that's probably a small enough corner case
11:21 ogra       together with the checks etc
11:21 mdz        pitti: I'm satisfied with that
11:21 pitti      it's certainly fine for me
11:21 mdz        ok
11:22 mdz        DONE
11:22 pitti      but I think it was important enough to talk about it
11:22 mdz        DOIT
11:22 ogra       phew
11:22 pitti      'k :)
11:22 mdz        any other business?
11:22 pitti      sleeeep
=== ogra finally opens a merlot
11:22 mdz        I would like to talk about scheduling meeting times
11:22 mdz        but we should do that when we have everyone here
11:22 mdz        I'll just send email to TB about it
11:22 pitti      at the beginning of next TB?
11:22 mjg59      Cool
11:22 \sh        ogra: grmpf...
11:23 mdz        workrave HATES ME
11:23 ogra       hit it
11:23 \sh        mdz: kill -9 ?
11:23 mdz        meeting adjourned

MeetingLogs/Technical_2005-11-29 (last edited 2008-08-06 16:28:37 by localhost)