Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 18:30UTC (2:30pm EDT) in #fedora-meeting on irc.freenode.net.
= Followups =
#topic Updates policy
#351 Create a policy for updates - status report on implementation https://fedorahosted.org/fesco/ticket/351 #382 Implementing Stable Release Vision https://fedorahosted.org/fesco/ticket/382
* Need work on stats to see trends with new policy. * Need to investigate a 'new features' repo setup. * Need to look at enforcement
= New business =
#416 Set EOL Date For Fedora 12 https://fedorahosted.org/fesco/ticket/416
* Since F14 was pushed out a week, should we move EOL for F12 as well?
Elections coming up.
* Note that FESCo (and FAMSCo and Board) elections are coming up.
= Fedora Engineering Services tickets =
https://fedorahosted.org/fedora-engineering-services/report/6
= Open Floor =
For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.
kevin
Kevin Fenzi said the following on 10/26/2010 12:36 PM Pacific Time:
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 18:30UTC (2:30pm EDT) in #fedora-meeting on irc.freenode.net.
= Followups =
#topic Updates policy
#351 Create a policy for updates - status report on implementation https://fedorahosted.org/fesco/ticket/351 #382 Implementing Stable Release Vision https://fedorahosted.org/fesco/ticket/382
- Need work on stats to see trends with new policy.
- Need to investigate a 'new features' repo setup.
- Need to look at enforcement
= New business =
#416 Set EOL Date For Fedora 12 https://fedorahosted.org/fesco/ticket/416
- Since F14 was pushed out a week, should we move EOL for F12 as well?
Elections coming up.
- Note that FESCo (and FAMSCo and Board) elections are coming up.
= Fedora Engineering Services tickets =
https://fedorahosted.org/fedora-engineering-services/report/6
= Open Floor =
For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.
kevin
We have some Fedora 15 features too.
https://fedoraproject.org/wiki/Category:FeatureReadyForFesco
John
On Tue, Oct 26, 2010 at 01:36:13PM -0600, Kevin Fenzi wrote:
If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.
https://fedorahosted.org/rel-eng/ticket/4224
Note: I'm just an informed outsider in this. I'm CC'ing jnovy, jdieter, and jkeating to this email to be sure they're aware.
-Toshio
=================================== #fedora-meeting: FESCO (2010-10-27) ===================================
Meeting started by nirik at 18:30:00 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-10-27/fesco.2010-10-27-...
Meeting summary --------------- * init process (nirik, 18:30:01)
* Updates policy / Vision implementation status (nirik, 18:36:20) * LINK: https://fedoraproject.org/wiki/Updates_Policy (nirik, 18:46:00) * LINK: https://fedoraproject.org/wiki/User:Kparal/Package_update_approaches (cwickert, 18:46:52) * LINK: https://fedoraproject.org/wiki/User:Kparal/Proposal:Package_update_policy (cwickert, 18:46:52) * LINK: https://fedoraproject.org/wiki/User:Adamwill/Proposal:Package_update_policy (cwickert, 18:46:52) * LINK: https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_... (cwickert, 18:46:59) * LINK: https://fedoraproject.org/wiki/Package_update_acceptance_criteria (cwickert, 18:46:59) * LINK: https://fedoraproject.org/wiki/Stable_release_updates_vision (cwickert, 18:47:05) * LINK: https://fedoraproject.org/wiki/Package_update_acceptance_criteria#All_other_... is different from https://fedoraproject.org/wiki/Updates_Policy#All_other_updates (cwickert, 18:51:02) * ACTION: cwickert will work on new features repo ideas (nirik, 19:00:51) * ACTION: SMParrish will work on metrics (nirik, 19:00:59)
* #416 Set EOL Date For Fedora 12 (nirik, 19:01:03) * AGREED: F12 eol will be 2010-12-02, moving forward eol dates will be the nearest weekday to 1 month from release (nirik, 19:07:33)
* Elections coming up. (nirik, 19:08:21) * LINK: http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations (nirik, 19:10:16)
* Kudos for F14 release (nirik, 19:10:39)
* #480 F15Feature - RemoveSETUID ( http://fedoraproject.org/wiki/Features/RemoveSETUID ) (nirik, 19:15:16) * AGREED: the feature is approved. (nirik, 19:26:46)
* Open Floor (nirik, 19:26:50) * LINK: https://fedorahosted.org/rel-eng/ticket/4224 (abadger1999, 19:27:32)
* break build inheritance between F14 and F15 and update deltarpm files (nirik, 19:27:56) * AGREED: Fesco is fine with the indicated plan of mass tagging, breaking inherit, and scrubbing old deltarpms for rawhide. (nirik, 19:35:31)
* Open Floor (nirik, 19:36:53)
Meeting ended at 19:39:44 UTC.
Action Items ------------ * cwickert will work on new features repo ideas * SMParrish will work on metrics
Action Items, by person ----------------------- * cwickert * cwickert will work on new features repo ideas * SMParrish * SMParrish will work on metrics * **UNASSIGNED** * (none)
People Present (lines said) --------------------------- * nirik (115) * cwickert (51) * pjones (29) * ajax (24) * abadger1999 (17) * notting (16) * mclasen (14) * mjg59 (14) * zodbot (9) * kylem (9) * SMParrish (6) * wwoods (6) * Southern_Gentlem (3) * adamw (1) * rbergeron (1) -- 18:30:00 <nirik> #startmeeting FESCO (2010-10-27) 18:30:00 <zodbot> Meeting started Wed Oct 27 18:30:00 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:30:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:30:01 <nirik> #meetingname fesco 18:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 18:30:01 <nirik> #topic init process 18:30:01 <zodbot> The meeting name has been set to 'fesco' 18:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 18:30:37 <pjones> yo. 18:30:39 <nirik> who all is around for meeting? 18:32:04 <pjones> just me and you I guess. 18:32:06 * notting is here 18:32:06 * nirik wonders if we have quorum today. 18:32:08 <pjones> ;) 18:32:10 <kylem> yo. 18:32:31 <pjones> mjg59 was around a few minutes ago. 18:34:11 * nirik waits a few to see if we get one more person for quorum 18:35:28 <mjg59> pjones: Hi 18:35:35 <mjg59> Sorry, briefly distracted 18:35:50 <nirik> cool. I think we can go ahead and get started. 18:36:01 <cwickert> am I late? 18:36:06 <nirik> cwickert: nope, just in time. ;) 18:36:09 <cwickert> ;) 18:36:13 <mjg59> cwickert: Fashionably so 18:36:20 <nirik> #topic Updates policy / Vision implementation status 18:36:20 <nirik> .fesco 351 18:36:20 <nirik> .fesco 382 18:36:22 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 18:36:26 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382 18:36:31 <nirik> SMParrish was going to look at more stats stuff. 18:36:38 <nirik> Also, I talked with lmacken about bodhi stats. 18:37:08 <nirik> He was going to generate them for us so we could see what was in them, and also try and do a 'pre release' 'post release' split for f14 18:37:32 <nirik> the next bodhi version will allow (I think) running them from cron/regularly. 18:38:21 <nirik> It seems like we are not making much progress to finishing this up. Anyone have ideas on how we could finish things before next elections? 18:38:32 * SMParrish sorry I'm late. 18:39:01 <SMParrish> nirik: was travelling last week. just got home yesterday and have not had time to work on the metrics issue 18:39:14 <nirik> ok. 18:39:18 <cwickert> I think we still suffer from unclear board statements 18:39:33 <pjones> cwickert: I think we're always going to suffer from that 18:39:52 <pjones> we should just interpret them as best we can and if that's really something they didn't want then we do it again :/ 18:39:55 <cwickert> I was talking to some board members and they were not happy with the "only security and bugfixes" thing ether 18:40:42 <notting> and...? internal board politics are a matter for the board. 18:41:19 <mjg59> The board's statement explicitly says " Stable releases should provide a consistent user experience throughout the lifecycle, and only fix bugs and security issues. " 18:41:22 <nirik> I'd really like to see us try the current policy for a bit. It may be too conservative, but we can adjust it if so down the road. 18:41:42 <nirik> we also were going to look into a 'new features' repo. 18:42:46 <nirik> perhaps we could set action items and people on the remaining tasks? 18:42:58 <nirik> SMParrish: work with lmacken on metrics ? 18:43:08 <cwickert> speaking of that, I was supposed to write a propsal on the new-features repo 18:43:19 <nirik> cwickert: yeah. 18:43:24 <kylem> i think this is mostly just a reflection fo the project as a whole, looking at #fedora-dveel you'd be hard pressed to find unilateral agreement on the interpretation of our vision. 18:43:58 <SMParrish> nirik: yes i will get with lmacken on the metrics issue 18:44:02 <pjones> nirik: yeah, I'm with you in that we need more observation to see what we've done. 18:44:03 <cwickert> i have two problems: it is hard to find the status quo as there are a lot of outdated update-something pages in the wiki now 18:44:25 <nirik> we should nuke or redirect the old ones to the current one. 18:44:30 <pjones> yep 18:44:40 <cwickert> the second problem is: two weeks ago a lot of questions were raised in the meeting 18:44:48 <cwickert> but they have not made it into the wiki 18:45:13 <nirik> questions on the new feature repo? or ? 18:45:19 <cwickert> ys 18:45:21 <cwickert> yes 18:45:33 <cwickert> how things work in bodhi and all that 18:45:46 <cwickert> but they are not on https://fedoraproject.org/wiki/Talk:Stable_release_updates_vision_implementa... 18:46:00 <cwickert> I guess I'll have to dig in the meeting logs 18:46:00 <nirik> https://fedoraproject.org/wiki/Updates_Policy 18:46:25 <nirik> that should be the page maintainers look at/follow. 18:46:51 <cwickert> there is a few more 18:46:52 <cwickert> https://fedoraproject.org/wiki/User:Kparal/Package_update_approaches 18:46:52 <cwickert> https://fedoraproject.org/wiki/User:Kparal/Proposal:Package_update_policy 18:46:52 <cwickert> https://fedoraproject.org/wiki/User:Adamwill/Proposal:Package_update_policy 18:46:59 <cwickert> https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_... 18:46:59 <cwickert> https://fedoraproject.org/wiki/Package_update_acceptance_criteria 18:47:05 <cwickert> https://fedoraproject.org/wiki/Stable_release_updates_vision 18:47:15 <nirik> the last one is the vision from the board. 18:47:34 <notting> anything in the User: namespace should obviously not be policy 18:47:37 <pjones> seems like we should make a category template for the various User: Proposal: ones and tag them so it says something at the top of the page or something. 18:47:37 <nirik> the rest should be removed probibly. (Although we do still have things to implement from the implementation_ideas page) 18:47:52 <pjones> (not that I've got any idea how to do that on the wiki) 18:48:21 <cwickert> the problem is there are conflictins statements 18:48:22 <abadger1999> pjones: Could just use {{draft}} 18:48:35 <pjones> nirik: I'm not sure I'm okay with us deciding to remove stuff under User: (unless it violates various codes of behavior of course) 18:48:38 <pjones> abadger1999: yeah 18:48:48 <abadger1999> pjones: Although you might want something that also says "rejected" or "alternative was implemented" 18:48:51 <pjones> abadger1999: I was thinking something a little stronger than that, but that's certainly the right idea. 18:48:52 <nirik> pjones: true. Althought we could add a 'note: this is NOT policy' or something. 18:49:22 <cwickert> e.g. the last paragraph of https://fedoraproject.org/wiki/Package_update_acceptance_criteria is not exactly what https://fedoraproject.org/wiki/Updates_Policy says 18:49:37 <pjones> nirik: yeah, something like {draft} but maybe a little more "don't use this as reference" since lots of people are used to reading draft documents as the canonical source for data ;) 18:50:03 <nirik> cwickert: about exceptions? 18:50:15 <cwickert> nirik, about criteria 18:50:33 * nirik is not following. 18:50:56 <nirik> The critical path / other updates sections? 18:51:02 <cwickert> https://fedoraproject.org/wiki/Package_update_acceptance_criteria#All_other_... is different from https://fedoraproject.org/wiki/Updates_Policy#All_other_updates 18:51:12 <cwickert> at least slightly 18:51:47 <cwickert> the information should be one one single page to make sure we have no contradictions and no redundancy 18:51:48 <nirik> well, I thought I copied it from the one page to the new one. 18:52:12 <nirik> yes, I copied Package_update_acceptance_criteria data into Updates_Policy 18:52:17 <nirik> where I messed up we should fix it. 18:52:38 <cwickert> ok, what else is left to do except a clean-up? 18:53:10 <cwickert> i guess https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_... 18:53:21 <nirik> if you see issues that are obviously me messing up the copy, just fix them. If it's something that should be changed, bring it up here and we can vote on it. 18:53:28 <nirik> right, we need: 18:53:31 <cwickert> i hope I can come up with a proposal for the next meeting, I'm just too busy in my dayjob 18:53:33 <nirik> metrics: how well is this working 18:53:44 <nirik> new feature repo: if it's fesable 18:53:47 <cwickert> what kind of metrics would that be? 18:54:26 <cwickert> i mean, how to judge if something is working? can we count how many people are cheating in bodhi? 18:54:37 <nirik> anything we could gather that would apply to: "Project members should be able to transparently measure or monitor a new updates process to objectively measure its effectiveness, and determine whether the updates process is achieving the aforementioned vision statements" 18:55:23 <nirik> we can count numbers of updates, numbers of bodhi comments/tests, number of karma submitters, number of bugs, etc. 18:55:49 <cwickert> so? what do we gain when counting the number of comments in bodhi? 18:56:05 <nirik> an increase in testing? 18:56:07 <cwickert> if even rel-eng gives "proxy karma" without testing 18:56:23 * nirik is happy to listen to any other metrics you think we should gather. 18:56:50 <cwickert> I'm sorry, I don't have any 18:57:07 <cwickert> but what I see at https://admin.fedoraproject.org/updates/openbox-3.4.11.2-5.fc14 makes me think we are not doing more testing than before 18:57:17 <wwoods> you're wrong. 18:57:20 <wwoods> provably so. 18:57:21 <cwickert> just an example, I'm sure there are plenty of this 18:57:33 <wwoods> that is an anecdote; the data say otherwise. 18:57:35 <nirik> the plural of anecdote is not data. 18:57:52 <nirik> anyhow, lets see what SMParrish comes up with and go from there? 18:58:05 <cwickert> wwoods, if two out of three testers are faking results, what have we gained? 18:58:17 <mjg59> One tester 18:58:25 <wwoods> furthermore, if that were actually correct - what would be the correct solution? Do *less* testing? 18:58:28 <cwickert> well... 18:58:34 * nirik notes we are over 15min on this topic. 18:59:11 <cwickert> wwoods, not have technical limitations that make people abuse the guidelines. 18:59:29 <wwoods> finding problems with a process should probably cause you to look for ways to improve the process 18:59:32 <cwickert> anyway, I'm happy for all numbers we can gather, but I doubt they are meaningful 19:00:00 <nirik> ok, anything further on updates? or shall we move on? 19:00:01 <wwoods> so - constructive suggestions on that topic would be excellent! probably not here and now, though. 19:00:09 <cwickert> +1 19:00:51 <nirik> #action cwickert will work on new features repo ideas 19:00:59 <nirik> #action SMParrish will work on metrics 19:01:03 <nirik> #topic #416 Set EOL Date For Fedora 12 19:01:03 <nirik> .fesco 416 19:01:08 <zodbot> nirik: #416 (Set EOL Date For Fedora 12) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/416 19:01:11 <cwickert> can we also have somebody to clean up the wiki? 19:01:15 <nirik> Since F14 was pushed out a week, should we move EOL for F12 as well? 19:01:27 <nirik> cwickert: I can try, but I also have been very busy. 19:01:38 <pjones> nirik: yeah, we should keep them in lock-step I guess. 19:01:45 <cwickert> +1 19:02:12 <ajax> sure, why not 19:02:14 <mjg59> nirik: +1 19:02:29 <nirik> ok, +1 from me too. 19:02:36 <Southern_Gentlem> suggest 12/1/2010 19:02:44 <nirik> Further on this topic, instead of us voting on it, do we want to just setup a general rule? 19:02:50 <pjones> nirik: yes 19:02:57 <nirik> ie, nearest weekday to 1 month from release. 19:03:00 <notting> ACK 19:03:04 <pjones> +1 19:03:07 <mjg59> +1 19:03:12 * mclasen is all for auto-EOL 19:03:13 <mclasen> +1 19:03:17 <ajax> +1 19:03:25 <nirik> that would make it 2010-12-02 for this case tho (2010-12-03 was suggested) 19:03:58 * notting is +1 to lockstep, +1 to auto-lockstep 19:04:20 <pjones> nirik: nearest to or first after? 19:04:31 <kylem> +1. 19:04:32 <nirik> pjones: we could do that I suppose. 19:04:41 <pjones> not that I really care. 19:04:41 * nirik doesn't feel too strongly either way. 19:05:22 <nirik> anyone object to 'nearest weekday 1 month from release +1 day' ? 19:05:37 <ajax> fine with me 19:05:50 <cwickert> same here 19:05:56 <Southern_Gentlem> why the +1 day? 19:06:11 <kylem> latency. 19:06:12 <kylem> :P 19:06:24 <nirik> I guess that just makes it more complex. 19:06:42 <nirik> so, lets just do nearest weekday to 1 month after release. 19:07:07 <pjones> I'm thinking "first weekday after" just because that means we prefer mondays to fridays. 19:07:18 <pjones> (well, on or after. gah.) 19:07:27 <ajax> also fine with me. 19:07:33 <nirik> #agreed F12 eol will be 2010-12-02, moving forward eol dates will be the nearest weekday to 1 month from release 19:07:42 <nirik> pjones: I don't know that it matters... 19:07:59 <pjones> fair enough. 19:08:19 <nirik> Some topics that are just announcements/notices: 19:08:21 <nirik> #topic Elections coming up. 19:08:31 <nirik> elections are starting up for board, fesco, famsco 19:09:18 <nirik> Everyone should vote. ;) 19:09:25 <kylem> lol 19:09:27 <pjones> +1 19:09:31 <ajax> early and often. 19:09:33 * nirik looks to see who is up from fesco... 19:09:44 <notting> ajax, cwickert, pjones, mjg59 19:09:45 <mjg59> Me, ajax, pjones, cwickert? 19:09:47 <mjg59> Yeah 19:09:52 <rbergeron> ...or nominate themselves for open positions :) 19:09:57 <nirik> Adam Jackson (ajax), Christoph Wickert (cwickert), Peter Jones (pjones), and Matthew Garrett (mjg59) 19:10:10 * nirik thanks notting for updating the page. 19:10:16 <nirik> http://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations 19:10:32 <nirik> moving on... 19:10:39 <cwickert> I haven't seen an announcement on devel list 19:10:39 <nirik> #topic Kudos for F14 release 19:10:42 * Southern_Gentlem crosses fingers that they all reapply for the job 19:10:58 <nirik> cwickert: yeah, not sure who is coordinating this time. ;( will find out tho. 19:11:11 <notting> nirik: i think everyone's coordinating their own? 19:11:24 <notting> do we want to designate someone to post to the devel list? 19:11:31 <nirik> I'd like to thank all the maintainers, qa folks, users and rel-eng for making F14 such a smooth release. :) 19:11:37 <cwickert> +1 19:11:39 <nirik> notting: oh, usually there's a coordinator. 19:11:51 <cwickert> especially for QA, adamw does a great job 19:12:10 <nirik> seconded. ;) 19:12:27 * adamw would like to thank all the people who did all the work 19:12:57 <nirik> I can find out if there is a coordinator this time, and if not, at least mail the devel-announce list about nominations being open. 19:13:14 <SMParrish> +1 kudos to all 19:13:20 <notting> nirik: wfm 19:13:22 <cwickert> nirik, there was something in the board list about coordination 19:13:24 <notting> nirik: thanks! 19:13:53 <nirik> ok, I had one f15 feature that I didn't note in time for the agenda. We could do it now, or wait until next week? 19:14:51 <cwickert> how about now? 19:14:54 <mjg59> Sure 19:14:55 <abadger1999> pjones, cwickert: Re: a template like {{draft}} I just made this for ya'll: https://fedoraproject.org/wiki/Template:Draft/declined Go ahead and change it if you want something slightly different. 19:15:12 <nirik> abadger1999: thanks! 19:15:15 * abadger1999 sorry for jumping in with that but has to leave soon 19:15:16 <nirik> #topic #480 F15Feature - RemoveSETUID ( http://fedoraproject.org/wiki/Features/RemoveSETUID ) 19:15:16 <nirik> .fesco 480 19:15:17 <zodbot> nirik: #480 (F15Feature - RemoveSETUID ( http://fedoraproject.org/wiki/Features/RemoveSETUID )) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/480 19:15:36 <pjones> abadger1999: excellent. 19:15:57 * cwickert looks 19:16:15 <nirik> I'm +1 on this. I don't know how hard it's going to be, but if anyone can get it to happen dwalsh can. ;) 19:16:39 <ajax> i'm only barely +1 to this since i still think capabilities are far too coarse-grained to be of much use 19:16:46 <mjg59> I'm also +1, though concerned about the degree to which things may end up breaking 19:17:01 <pjones> I'm +0 to this for the sam reason ajax is barely +1 to it. 19:17:02 <mjg59> I can't see it /reducing/ security, but I don't think it's as big a win as it could be 19:17:22 <ajax> but f15's xserver is already shipping non-setuid, so, whatever. 19:17:50 <notting> ajax: sys_admin or raw_io? 19:18:01 <ajax> notting: both those and also dac_override 19:18:07 <mclasen> is the dependency list on the tracker bug complete ? 19:18:11 <mclasen> 24 sounds low... 19:18:29 <nirik> it does seem low yeah. 19:19:14 <notting> ajax: that doesn't remove much. if anything. 19:19:17 <ajax> notting: if that sounds like zero effective reduction in privileges, that's because it's no effective reduction in privs. 19:19:22 <ajax> so, like i said. 19:19:38 <ajax> hey cool we can use capabilities! if only that were meaningful! 19:19:50 <mclasen> would be good if the feature page had some advice on how to find out the 'correct caps' to use 19:19:56 <notting> i'm moderately for the idea, but it remains to see if we'll come up with anything useful 19:20:17 <ajax> xserver might be a special case, but really anything that needs dac_override or sys_admin is trivially equivalent to root 19:20:27 <pjones> mclasen: the problem is that the capabilities are so poorly thought out that that's a non-trivial (and possibly non-meaningful) exercise. 19:20:41 <mclasen> and one that breaks at runtime if you get it wrong ? 19:20:48 <ajax> mclasen: indeed. 19:20:49 <pjones> yep. 19:21:41 <ajax> i would say i get the feeling the caps were designed by someone who had never tried to root a machine, but that would imply that i thought they were designed period. 19:21:54 <mclasen> so we need individual testing attention for each binary that gets that treatment, I guess 19:22:42 <ajax> yeah. again, if dan wants to drive that, great. 19:22:58 <notting> ajax: 'designed by someone who only wanted to remove setuid from ping, other things are an afterthought'? 19:23:34 <ajax> notting: that's a bit closer, yeah. 19:24:27 <ajax> anyway. +1 to the feature even though it's of the most marginal utility. 19:25:04 <nirik> so where are we here... 19:25:11 <nirik> +3 I see 19:25:19 <cwickert> +1, see what it brings 19:25:31 <SMParrish> +1 19:26:13 <pjones> I guess I could be +1 despite limited utility. It's not a bad thing to do per se. 19:26:46 <nirik> #agreed the feature is approved. 19:26:50 <nirik> #topic Open Floor 19:26:55 <nirik> Anything for open floor? 19:26:57 * mclasen adds comments to the feature page and gives a +1 19:27:00 <ajax> hah! the bugs even cite Xorg as the example. 19:27:09 * ajax ahead of the curve 19:27:32 <abadger1999> https://fedorahosted.org/rel-eng/ticket/4224 19:27:39 <nirik> ah yes, 19:27:56 <nirik> #topic break build inheritance between F14 and F15 and update deltarpm files 19:28:07 <nirik> .rel-eng 4224 19:28:09 <zodbot> nirik: Ticket #4230 (task created): build tag override request for eclipse-3.6.1-2.fc14 || Ticket #4229 (task closed): Retire OpenOffice.org from F15 || Ticket #4229 (task created): Retire OpenOffice.org from F15 || Ticket #4228 (task created): Buildroot override request for libtorrent || Ticket #4227 (task created): tag request: dist-f14-override for libgda-4.2.0-1.fc14 || Ticket #4226 (defect closed): (11 more messages) 19:28:15 <abadger1999> Oxf13: You around for this? 19:28:16 <nirik> oops. thats not right. ;) 19:28:34 <ajax> eesh, this looks vile. 19:29:15 <nirik> yes, yes it does. 19:29:36 <abadger1999> This comment is probably the best summary of the problem: https://fedorahosted.org/rel-eng/ticket/4224#comment:6 19:29:51 <abadger1999> The initial report has the proposed solution. 19:30:31 <nirik> given that it falls back to the full rpm ok and that deltas are only somewhat usefull in rawhide anyhow... 19:30:32 <abadger1999> I think Oxf13 would like fesco input because we normally don't break build inheritance by itself... although we do in practice if we do a mass rebuild 9but once again, that would normally be later in the cycle) 19:30:42 <nirik> this is just f15 right? 19:30:48 <abadger1999> Correct. 19:30:55 * nirik whews 19:31:11 <abadger1999> It won't affect f14 as jnovy isn't going to push the new xz back. 19:31:19 <nirik> thank goodness. 19:31:32 <mclasen> whats the consequence of broken build inheritance ? people have to build their stuff for rawhide ? 19:31:40 <mclasen> doesn't sound too onerous to me 19:31:55 <ajax> mclasen: yeah, f14 builds won't automatically bubble to f15. 19:31:56 <abadger1999> mclasen: Correct. A build for F14 won't automatically go to F15. 19:32:11 <nirik> if we nuke existing deltas does that mean we would need a compose to rebuild them all? (ie, a long ass one) 19:32:35 <abadger1999> nirik: No, the idea is that we'll only have deltas for packages built after that time. 19:32:41 <nirik> ok, good. 19:32:45 <notting> rawhide deltas are just against the prior tree 19:32:55 <abadger1999> nirik: The reason is that the final package on the user's system will have been built with the xz on the user's system. 19:33:07 <nirik> I'm fine with the plan then... tag, break inhert, nuke deltas, move on. 19:33:09 <abadger1999> nirik: And when the update package was old, that's what's causing the breakage. 19:34:02 <pjones> yeah, I'm fine with this plan. 19:34:14 <ajax> works for me 19:34:22 <SMParrish> based on that I'm good with it 19:34:40 <nirik> that's +4 I think. 19:34:43 <mclasen> +1 19:35:01 <kylem> hrm. 19:35:04 <mjg59> +1, I think 19:35:05 <kylem> +1. 19:35:12 <mjg59> I can't see anything obviouly better 19:35:16 <kylem> i'd like t think about it more though. 19:35:31 <nirik> #agreed Fesco is fine with the indicated plan of mass tagging, breaking inherit, and scrubbing old deltarpms for rawhide. 19:35:34 <ajax> well, besides turning off deltas 19:35:52 <nirik> well, deltas are not usually that usefull in rawhide, unless you make sure to update every single day. 19:36:27 <nirik> and even then, if you had an day out of date mirror, etc. 19:36:40 <abadger1999> Cool. 19:36:48 * abadger1999 has to vamoose now. 19:36:52 <ajax> yeah, i really don't see much benefit in drpms for rawhide 19:36:53 <nirik> #topic Open Floor 19:37:05 <nirik> any further open floor items? or shall we wrap up? 19:37:06 <mclasen> do we have a date for that event ? 19:37:33 <nirik> mclasen: I guess when rel-eng is ready... it should be announced, etc. 19:37:46 <mclasen> sure, sounds fine 19:37:54 * mclasen was just making sure its not happening tomorrow 19:38:40 <nirik> I think the new xz has landed, but the only harm right now is that deltarpms don't work. 19:39:10 * nirik will close out the meeting in a few here if nothing comes up. 19:39:13 <notting> right, and since they fallback, i wasn't thinking it was OMG critical 19:39:34 <nirik> yeah. 19:39:39 <nirik> ok, thanks for coming everyone! 19:39:44 <nirik> #endmeeting
On 10/28/2010 01:11 AM, Kevin Fenzi wrote:
* #480 F15Feature - RemoveSETUID ( http://fedoraproject.org/wiki/Features/RemoveSETUID ) (nirik, 19:15:16) * AGREED: the feature is approved. (nirik, 19:26:46)
This feature is now approved and I see bugs get filed. The documentation and guidelines are very incomplete. How does one figure out which file capabilities are needed by the programs I maintain that currently use setuid? Help, please.
Rahul
On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote:
This feature is now approved and I see bugs get filed. The documentation and guidelines are very incomplete. How does one figure out which file capabilities are needed by the programs I maintain that currently use setuid? Help, please.
Probably: remove setuid bit, run, see what breaks. strace may be useful
[pp@the ~]$ strace ./rsh localhost 2>&1|grep EACCES bind(3, {sa_family=AF_INET6, sin6_port=htons(1023), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EACCES (Permission denied)
-> needs CAP_NET_BIND_SERVICE. It didn't seem to output any error to the user, so the lacking permissions may be well-hidden.
https://wiki.archlinux.org/index.php/Using_File_Capabilities_Instead_Of_Setu... seems to have a list btw., which may or may not be correct.
Do note that removing suid from some programs is a bad idea: "Warning: Do not use it, because mount and umount can not do some checks, then users can mount/umount filesystems that do not have permission." (probably those checks could/should be implemented upstream, if they're not already there)
So it's a feature that could introduce new vulnerabilities if done wrong, but it's certainly worth doing, carefully. If uncertain, ask.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/28/2010 04:14 AM, Pekka Pietikainen wrote:
On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote:
This feature is now approved and I see bugs get filed. The documentation and guidelines are very incomplete. How does one figure out which file capabilities are needed by the programs I maintain that currently use setuid? Help, please.
Probably: remove setuid bit, run, see what breaks. strace may be useful
[pp@the ~]$ strace ./rsh localhost 2>&1|grep EACCES bind(3, {sa_family=AF_INET6, sin6_port=htons(1023), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EACCES (Permission denied)
-> needs CAP_NET_BIND_SERVICE. It didn't seem to output any error to the user, so the lacking permissions may be well-hidden.
https://wiki.archlinux.org/index.php/Using_File_Capabilities_Instead_Of_Setu... seems to have a list btw., which may or may not be correct.
Do note that removing suid from some programs is a bad idea: "Warning: Do not use it, because mount and umount can not do some checks, then users can mount/umount filesystems that do not have permission." (probably those checks could/should be implemented upstream, if they're not already there)
So it's a feature that could introduce new vulnerabilities if done wrong, but it's certainly worth doing, carefully. If uncertain, ask.
I think we can refine this as we go. Steve Grubb is a great source of information on handling capabilities. One other goal of this is to find the apps that need full setuid and update rpmlint/whitelist with those apps. su, sudo, ksu, userhelper all need full setuid (capabilities).
If your setuid app is covered by SELinux policy we know in the rules which capabilities are used in the application, so you can work with the SELinux team to get the list. In some cases you might have capabilities that you do not need. For example newrole needs to send audit messages, (cap_audit_write) but when we coded it up originally it was setuid root, and started as root, then executed the setuid(USERUID) call, requiring the cap_setuid capability. Then it dropped capabilities requiring additional capabilities. By moving the code to file capabilities, I was able to give it just cap_audit_write and drop the code to change the setuid and drop capabilities, eliminating the need for these capabilities.
On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote:
On 10/28/2010 01:11 AM, Kevin Fenzi wrote:
- #480 F15Feature - RemoveSETUID ( http://fedoraproject.org/wiki/Features/RemoveSETUID ) (nirik, 19:15:16)
- AGREED: the feature is approved. (nirik, 19:26:46)
This feature is now approved and I see bugs get filed. The documentation and guidelines are very incomplete. How does one figure out which file capabilities are needed by the programs I maintain that currently use setuid? Help, please.
More to the point, I can easily see the setuid bit easily on a binary.
How do I tell if these strange/hidden "capabilities" are present on a binary? 'ls' doesn't mention anything.
Rich.
On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote:
On 10/28/2010 01:11 AM, Kevin Fenzi wrote:
- #480 F15Feature - RemoveSETUID (
http://fedoraproject.org/wiki/Features/RemoveSETUID ) (nirik, 19:15:16)
- AGREED: the feature is approved. (nirik, 19:26:46)
This feature is now approved and I see bugs get filed. The documentation and guidelines are very incomplete. How does one figure out which file capabilities are needed by the programs I maintain that currently use setuid? Help, please.
More to the point, I can easily see the setuid bit easily on a binary.
How do I tell if these strange/hidden "capabilities" are present on a binary? 'ls' doesn't mention anything.
getcap
joe
"JN" == Joe Nall joe@nall.com writes:
JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden "capabilities" are present on a binary? 'ls' doesn't mention anything.
JN> getcap
Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages.
I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it.
- J<
On Thu, 28 Oct 2010, Jason L Tibbitts III wrote:
"JN" == Joe Nall joe@nall.com writes:
JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden "capabilities" are present on a binary? 'ls' doesn't mention anything.
JN> getcap
Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages.
I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it.
Yup, rpm 4.7.0 was the first one to support file capabilities. It's use is tracked with rpmlib(FileCaps) dependency, making packages utilizing the feature uninstallable with any older rpm versions, and of course trying to build such packages on older versions will barf out with a errors.
It should be possible to have EPEL define a macro that turns %caps(foo) into an %attr() with SUID bit set, but blindly enabling SUID bits might not be such a hot idea...
- Panu -
On Thu, Oct 28, 2010 at 11:08:00PM +0100, Richard W.M. Jones wrote:
On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote:
On 10/28/2010 01:11 AM, Kevin Fenzi wrote:
- #480 F15Feature - RemoveSETUID ( http://fedoraproject.org/wiki/Features/RemoveSETUID ) (nirik, 19:15:16)
- AGREED: the feature is approved. (nirik, 19:26:46)
This feature is now approved and I see bugs get filed. The documentation and guidelines are very incomplete. How does one figure out which file capabilities are needed by the programs I maintain that currently use setuid? Help, please.
More to the point, I can easily see the setuid bit easily on a binary.
How do I tell if these strange/hidden "capabilities" are present on a binary? 'ls' doesn't mention anything.
You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc. See also
http://people.redhat.com/sgrubb/libcap-ng/index.html
Regards, Daniel
On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote:
You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc.
Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument.
Rahul
On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote:
On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote:
You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc.
Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument.
In theory there's nothing preventing this. Deciding on/defining a concise display of capabilities info that doesn't mess up the formatting of ps/ls/etc is even tricker than with SELinux -Z because of the length of capabilities to display. eg, pscap for dhclient which has just 5 capabilities is showing
'dac_override, net_bind_service, net_admin, net_raw, sys_admin'
There are 32 possible capabilites, so you'll quickly exceed the width of terminals just listing capabilities, in this format. You could try and decide on shortened names to < 5 characters each, but it isn't going to be so readable, nor very short for lots of caps
Regards, Daniel
On Fri, Oct 29, 2010 at 4:48 PM, Daniel P. Berrange wrote:
There are 32 possible capabilites, so you'll quickly exceed the width of terminals just listing capabilities, in this format. You could try and decide on shortened names to < 5 characters each, but it isn't going to be so readable, nor very short for lots of caps
w, r, x are not really that readable either. It is just short, familiar and memorable. once we get short notations with a option to list what it means in full, we can adopt to that.
Rahul
On Fri, Oct 29, 2010 at 04:55:44PM +0530, Rahul Sundaram wrote:
On Fri, Oct 29, 2010 at 4:48 PM, Daniel P. Berrange wrote:
There are 32 possible capabilites, so you'll quickly exceed the width of terminals just listing capabilities, in this format. You could try and decide on shortened names to < 5 characters each, but it isn't going to be so readable, nor very short for lots of caps
w, r, x are not really that readable either. It is just short, familiar and memorable. once we get short notations with a option to list what it means in full, we can adopt to that.
You only have 3 letters to remember the name of and you encounter them on a daily basis, so its easily rememberable. Give every capability even a 5 letter long code and few will ever be able to remember what they mean.
Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/29/2010 07:18 AM, Daniel P. Berrange wrote:
On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote:
On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote:
You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc.
Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument.
In theory there's nothing preventing this. Deciding on/defining a concise display of capabilities info that doesn't mess up the formatting of ps/ls/etc is even tricker than with SELinux -Z because of the length of capabilities to display. eg, pscap for dhclient which has just 5 capabilities is showing
'dac_override, net_bind_service, net_admin, net_raw, sys_admin'
There are 32 possible capabilites, so you'll quickly exceed the width of terminals just listing capabilities, in this format. You could try and decide on shortened names to < 5 characters each, but it isn't going to be so readable, nor very short for lots of caps
Regards, Daniel
BTW I believe we now have > 32 capabilities, I believe there can now be upto 64 capabilities, although I think there are only a couple added to the second bitmask so far.
On Fri, 2010-10-29 at 12:18 +0100, Daniel P. Berrange wrote:
On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote:
On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote:
You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc.
Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument.
In theory there's nothing preventing this. Deciding on/defining a concise display of capabilities info that doesn't mess up the formatting of ps/ls/etc
I don't think you need to display them, just display something that says "this is more than it seems" ... like ACLs. Something as simple as "-rwcr-xr-x." instead of "-rwsr-xr-x." for setuid.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/29/2010 08:32 AM, James Antill wrote:
On Fri, 2010-10-29 at 12:18 +0100, Daniel P. Berrange wrote:
On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote:
On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote:
You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc.
Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument.
In theory there's nothing preventing this. Deciding on/defining a concise display of capabilities info that doesn't mess up the formatting of ps/ls/etc
I don't think you need to display them, just display something that says "this is more than it seems" ... like ACLs. Something as simple as "-rwcr-xr-x." instead of "-rwsr-xr-x." for setuid.
Seems like a good idea for a bug report...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/29/2010 08:32 AM, James Antill wrote:
On Fri, 2010-10-29 at 12:18 +0100, Daniel P. Berrange wrote:
On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote:
On Fri, Oct 29, 2010 at 2:26 PM, Daniel P. Berrange wrote:
You want the libcap-ng-utils RPMs which provides a bunch of useful tools for this, filecap, netcap, pscap, etc.
Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument.
In theory there's nothing preventing this. Deciding on/defining a concise display of capabilities info that doesn't mess up the formatting of ps/ls/etc
I don't think you need to display them, just display something that says "this is more than it seems" ... like ACLs. Something as simple as "-rwcr-xr-x." instead of "-rwsr-xr-x." for setuid.
https://bugzilla.redhat.com/show_bug.cgi?id=647786
On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote:
Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument.
FWIW, colorized ls seems to already recognize them. Setuid binaries are gray text on a red background, while binaries with capabilities set are black text on a red background.
On Fri, Oct 29, 2010 at 12:41:07PM +0100, Daniel P. Berrange wrote:
You only have 3 letters to remember the name of and you encounter them on a daily basis, so its easily rememberable. Give every capability even a 5 letter long code and few will ever be able to remember what they mean.
Perhaps we can use obscure unicode glyphs. :)
Matthew Miller mattdm@mattdm.org writes:
On Fri, Oct 29, 2010 at 02:32:52PM +0530, Rahul Sundaram wrote:
Is there any particular reason, the regular tools that users already use cannot be modified to display the appropriate info, like SELinux and -Z argument.
FWIW, colorized ls seems to already recognize them. Setuid binaries are gray text on a red background, while binaries with capabilities set are black text on a red background.
From coreutils/src/ls.c:
/* Note has_capability() adds around 30% runtime to `ls --color` */
Andreas.
On Fri, Oct 29, 2010 at 06:16:32PM +0200, Andreas Schwab wrote:
From coreutils/src/ls.c:
/* Note has_capability() adds around 30% runtime to `ls --color` */Andreas.
I think that's something we can live with. Colorizing is already significant overhead, and if performance is important, don't do it:
/usr$ time ls --color=yes -R > /dev/null real 0m23.871s user 0m1.315s sys 0m22.513s
/usr$ time ls --color=no -R > /dev/null real 0m3.707s user 0m0.636s sys 0m3.060s
(Actually average of three runs, after discarding one.)
On Fri, 2010-10-29 at 12:31 -0400, Matthew Miller wrote:
I think that's something we can live with. Colorizing is already significant overhead, and if performance is important, don't do it:
I'm color-blind (I see colors but I don't distinguish them) quite strongly. In addition, I usually work on a reverse intensity terminal (light on dark), that makes ls colors anti-ergonomic.
I already considered the introduction of a default shell alias to force coloring as particularly wicked.
Thus: -1 for indications by colors.
On Fri, Oct 29, 2010 at 07:00:54PM +0200, Patrick MONNERAT wrote:
I'm color-blind (I see colors but I don't distinguish them) quite strongly. In addition, I usually work on a reverse intensity terminal (light on dark), that makes ls colors anti-ergonomic.
I already considered the introduction of a default shell alias to force coloring as particularly wicked.
Thus: -1 for indications by colors.
It absolutely cannot be the only indication. I did not mean to suggest that.
However, it is a very valuable indicator for those able to take advantage of it.
On Fri, 2010-10-29 at 12:05 -0400, Matthew Miller wrote:
On Fri, Oct 29, 2010 at 12:41:07PM +0100, Daniel P. Berrange wrote:
You only have 3 letters to remember the name of and you encounter them on a daily basis, so its easily rememberable. Give every capability even a 5 letter long code and few will ever be able to remember what they mean.
Perhaps we can use obscure unicode glyphs. :)
you said 64 capabilities, right? that's not so many. Chinese and Japanese users are laughing, we can just use some basic Chinese characters. For our European users we can combine Roman, Greek and Cyrillic alphabets and require all our users to have decent liberal education. Anyone want to suggest something for Indian and African users? :)
Americans, well, they're just a lost cause...perhaps the logos of popular sports teams?
On 29/10/10 04:15, Jason L Tibbitts III wrote:
"JN" == Joe Nalljoe@nall.com writes:
JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden "capabilities" are present on a binary? 'ls' doesn't mention anything.
JN> getcap
Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages.
I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it.
I've just come across another issue with this. I use the "tmpfs" plugin with mock usually, and it appears that tmpfs doesn't support the necessary file capabilities, as I get these errors when setting up the buildroot:
DEBUG util.py:267: Error unpacking rpm package iputils-20101006-2.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported DEBUG util.py:267: Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported
If I disable the tmpfs plugin, so mock uses the ext3 filesystem I have on /var/lib/mock, the build succeeds. So at least I have a workaround but I'd like to have tmpfs working as it *really* improves performance.
Paul.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/01/2010 09:44 AM, Paul Howarth wrote:
On 29/10/10 04:15, Jason L Tibbitts III wrote:
> "JN" == Joe Nalljoe@nall.com writes:
JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden "capabilities" are present on a binary? 'ls' doesn't mention anything.
JN> getcap
Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages.
I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it.
I've just come across another issue with this. I use the "tmpfs" plugin with mock usually, and it appears that tmpfs doesn't support the necessary file capabilities, as I get these errors when setting up the buildroot:
DEBUG util.py:267: Error unpacking rpm package iputils-20101006-2.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported DEBUG util.py:267: Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported
If I disable the tmpfs plugin, so mock uses the ext3 filesystem I have on /var/lib/mock, the build succeeds. So at least I have a workaround but I'd like to have tmpfs working as it *really* improves performance.
Paul.
Paul is this because NOSUID is set on tmpfs?
On Mon, 01 Nov 2010 11:04:09 -0400 Daniel J Walsh dwalsh@redhat.com wrote:
On 11/01/2010 09:44 AM, Paul Howarth wrote:
On 29/10/10 04:15, Jason L Tibbitts III wrote:
>> "JN" == Joe Nalljoe@nall.com writes:
JN> On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote:
More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden "capabilities" are present on a binary? 'ls' doesn't mention anything.
JN> getcap
Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages.
I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it.
I've just come across another issue with this. I use the "tmpfs" plugin with mock usually, and it appears that tmpfs doesn't support the necessary file capabilities, as I get these errors when setting up the buildroot:
DEBUG util.py:267: Error unpacking rpm package iputils-20101006-2.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported DEBUG util.py:267: Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported
If I disable the tmpfs plugin, so mock uses the ext3 filesystem I have on /var/lib/mock, the build succeeds. So at least I have a workaround but I'd like to have tmpfs working as it *really* improves performance.
Paul.
Paul is this because NOSUID is set on tmpfs?
The tmpfs is set up by mock and I can't see anywhere in the mock code that it sets nosuid. I can't tell from outside mock what options it's using as it also uses a namespace. If I just run "mount" from within a package build I don't get any output.
Any suggestions?
Paul.
On Mon, Nov 01, 2010 at 07:19:15PM +0000, Paul Howarth wrote:
Any suggestions?
We've encountered some funny things about tmpfs before: It doesn't support O_DIRECT at all, for example, necessitating workarounds in libguestfs/qemu. Just speculating, but maybe it doesn't support extended attributes, or has only partial support for them?
Rich.
Yeah, it looks like the capabilities thing has broken my buildsystem:
Error unpacking rpm package iputils-20101006-2.fc15.x86_64 error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported
Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported
I don't use the mock tmpfs plugin; I just have a big tmpfs mounted on /mock that everything is built in.
grep mock /proc/mounts
tmpfs /mock tmpfs rw,rootcontext=unconfined_u:object_r:default_t:s0,seclabel,relatime,size=10485760k,nr_inodes=1048576,mode=2775,gid=219 0 0
I'm thinking that tmpfs simply doesn't support capabilities, which would be... unfortunate.
- J<
fre 2010-10-29 klockan 08:32 -0400 skrev James Antill:
I don't think you need to display them, just display something that says "this is more than it seems" ... like ACLs. Something as simple as "-rwcr-xr-x." instead of "-rwsr-xr-x." for setuid.
I.e. kind of like what "ls --color" does?
Regards Henrik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/01/2010 04:31 PM, Jason L Tibbitts III wrote:
Yeah, it looks like the capabilities thing has broken my buildsystem:
Error unpacking rpm package iputils-20101006-2.fc15.x86_64 error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported
Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported
I don't use the mock tmpfs plugin; I just have a big tmpfs mounted on /mock that everything is built in.
grep mock /proc/mounts
tmpfs /mock tmpfs rw,rootcontext=unconfined_u:object_r:default_t:s0,seclabel,relatime,size=10485760k,nr_inodes=1048576,mode=2775,gid=219 0 0
I'm thinking that tmpfs simply doesn't support capabilities, which would be... unfortunate.
- J<
Opened a bug on this.
https://bugzilla.redhat.com/show_bug.cgi?id=648653
Here's another problem:
Prelink erases file-based capabilities. https://bugzilla.redhat.com/show_bug.cgi?id=456105
Rich.
On Thu, Oct 28, 2010 at 11:14:08AM +0300, Pekka Pietikainen wrote:
On Thu, Oct 28, 2010 at 12:44:52PM +0530, Rahul Sundaram wrote:
This feature is now approved and I see bugs get filed. The documentation and guidelines are very incomplete. How does one figure out which file capabilities are needed by the programs I maintain that currently use setuid? Help, please.
Probably: remove setuid bit, run, see what breaks. strace may be useful
Don't do that. You have to *always* read the application source code to verify that the change is safe. You have to verify all relevant shared libraries too.
[pp@the ~]$ strace ./rsh localhost 2>&1|grep EACCES bind(3, {sa_family=AF_INET6, sin6_port=htons(1023), inet_pton(AF_INET6, "::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EACCES (Permission denied)
-> needs CAP_NET_BIND_SERVICE. It didn't seem to output any error to the user, so the lacking permissions may be well-hidden.
That's completely wrong and dangerous point of view...
Karel
On Mon, 01.11.10 20:28, Richard W.M. Jones (rjones@redhat.com) wrote:
On Mon, Nov 01, 2010 at 07:19:15PM +0000, Paul Howarth wrote:
Any suggestions?
We've encountered some funny things about tmpfs before: It doesn't support O_DIRECT at all, for example, necessitating workarounds in libguestfs/qemu. Just speculating, but maybe it doesn't support extended attributes, or has only partial support for them?
tmpfs as of now does not support user xattrs. Only SELinux labels are supported.
Lennart
Pardon the thread necromancy,
So recently I had cause to look at http://fedoraproject.org/wiki/Features/RemoveSETUID again (I was investigating the X server permissions for an unrelated reason).
Now, that page links to http://people.redhat.com/sgrubb/libcap-ng/index.html
which attempts to explain the value of capabilities, etc. I was following along on all of this, and I understand that capabilities have some (non-negligible) value if you don't have e.g. cap_sys_admin. But then I got to the point where it says:
"But they still have uid 0, which typical system installation allows root to do things. For example, /bin/sh is 0755 and /bin is also 0755 perms. A disarmed root process can still trojan a system. But what if we got rid of all the read/write permissions for root?"
So...right, "we can do these small changes, and then if we do this BIG CHANGE, it all works!". But this feature doesn't include BIG CHANGE, and there are no plans to, right? Or is chmod u-rwx g-rwx on the root filesystem really in the cards?
Now, https://fedoraproject.org/wiki/Features/LowerProcessCapabilities appears to claim 100% completion on this for Fedora 12, but none (?) of it happened?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/21/2010 11:47 AM, Colin Walters wrote:
Pardon the thread necromancy,
So recently I had cause to look at http://fedoraproject.org/wiki/Features/RemoveSETUID again (I was investigating the X server permissions for an unrelated reason).
Now, that page links to http://people.redhat.com/sgrubb/libcap-ng/index.html
which attempts to explain the value of capabilities, etc. I was following along on all of this, and I understand that capabilities have some (non-negligible) value if you don't have e.g. cap_sys_admin. But then I got to the point where it says:
"But they still have uid 0, which typical system installation allows root to do things. For example, /bin/sh is 0755 and /bin is also 0755 perms. A disarmed root process can still trojan a system. But what if we got rid of all the read/write permissions for root?"
So...right, "we can do these small changes, and then if we do this BIG CHANGE, it all works!". But this feature doesn't include BIG CHANGE, and there are no plans to, right? Or is chmod u-rwx g-rwx on the root filesystem really in the cards?
Now, https://fedoraproject.org/wiki/Features/LowerProcessCapabilities appears to claim 100% completion on this for Fedora 12, but none (?) of it happened?
File capabilities just limit the number of capabilities an application starts with. setuid app means an app starts with all 32, a couple of new ones, capabilities. Then it is up to the app developer to drop the capabilities when the app is done using them. Going to file capabilities just limits the capabilities an application starts with to the specified capabilities. The application developer should still drop the capabilities once they no longer need them. It helps in the case of a bug in an application, that does not drop capabilities.
On Tue, Dec 21, 2010 at 3:21 PM, Daniel J Walsh dwalsh@redhat.com wrote:
File capabilities just limit the number of capabilities an application starts with. setuid app means an app starts with all 32, a couple of new ones, capabilities. Then it is up to the app developer to drop the capabilities when the app is done using them. Going to file capabilities just limits the capabilities an application starts with to the specified capabilities. The application developer should still drop the capabilities once they no longer need them. It helps in the case of a bug in an application, that does not drop capabilities.
I understand the goal of getting fewer capabilities (however, I think switching setuid to cap_sys_admin is at best pointless, at worst an obfuscation).
But you didn't answer my question - does the scope of this plan include a Unix mode 005 /bin, etc. or not?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/21/2010 03:50 PM, Colin Walters wrote:
On Tue, Dec 21, 2010 at 3:21 PM, Daniel J Walsh dwalsh@redhat.com wrote:
File capabilities just limit the number of capabilities an application starts with. setuid app means an app starts with all 32, a couple of new ones, capabilities. Then it is up to the app developer to drop the capabilities when the app is done using them. Going to file capabilities just limits the capabilities an application starts with to the specified capabilities. The application developer should still drop the capabilities once they no longer need them. It helps in the case of a bug in an application, that does not drop capabilities.
I understand the goal of getting fewer capabilities (however, I think switching setuid to cap_sys_admin is at best pointless, at worst an obfuscation).
But you didn't answer my question - does the scope of this plan include a Unix mode 005 /bin, etc. or not?
No
Colin Walters píše v Út 21. 12. 2010 v 11:47 -0500:
"But they still have uid 0, which typical system installation allows root to do things. For example, /bin/sh is 0755 and /bin is also 0755 perms. A disarmed root process can still trojan a system. But what if we got rid of all the read/write permissions for root?"
So...right, "we can do these small changes, and then if we do this BIG CHANGE, it all works!". But this feature doesn't include BIG CHANGE, and there are no plans to, right?
No. The original plans didn't count with the fact that changing permissions by owner does not require any capabilities either.
If an attacker were controlling a process running with uid 0 and no capabilities at all, and /bin/sh were 0555, nothing prevents the attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes any attempts to change the file permissions rather pointless. Mirek
2010/12/21 Miloslav Trmač mitr@volny.cz:
If an attacker were controlling a process running with uid 0 and no capabilities at all, and /bin/sh were 0555, nothing prevents the attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes any attempts to change the file permissions rather pointless.
Ah, of course. That makes sense, thanks!
But it leaves me feeling pretty uncertain about the value of trying to subset capabilities...
On Tue, Dec 21, 2010 at 10:37:44PM +0100, Miloslav Trmač wrote devel:
Colin Walters píše v Út 21. 12. 2010 v 11:47 -0500:
"But they still have uid 0, which typical system installation allows root to do things. For example, /bin/sh is 0755 and /bin is also 0755 perms. A disarmed root process can still trojan a system. But what if we got rid of all the read/write permissions for root?"
So...right, "we can do these small changes, and then if we do this BIG CHANGE, it all works!". But this feature doesn't include BIG CHANGE, and there are no plans to, right?
No. The original plans didn't count with the fact that changing permissions by owner does not require any capabilities either.
If an attacker were controlling a process running with uid 0 and no capabilities at all, and /bin/sh were 0555, nothing prevents the attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes any attempts to change the file permissions rather pointless.
Ok, so who says that the files must be owned by root? Make them owned by some other user -- say, bin? (or does that have another use that my google search isn't coming up with?)
i.grok@comcast.net píše v Út 21. 12. 2010 v 18:52 -0500:
On Tue, Dec 21, 2010 at 10:37:44PM +0100, Miloslav Trmač wrote devel:
Colin Walters píše v Út 21. 12. 2010 v 11:47 -0500:
"But they still have uid 0, which typical system installation allows root to do things. For example, /bin/sh is 0755 and /bin is also 0755 perms. A disarmed root process can still trojan a system. But what if we got rid of all the read/write permissions for root?"
So...right, "we can do these small changes, and then if we do this BIG CHANGE, it all works!". But this feature doesn't include BIG CHANGE, and there are no plans to, right?
No. The original plans didn't count with the fact that changing permissions by owner does not require any capabilities either.
If an attacker were controlling a process running with uid 0 and no capabilities at all, and /bin/sh were 0555, nothing prevents the attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes any attempts to change the file permissions rather pointless.
Ok, so who says that the files must be owned by root? Make them owned by some other user -- say, bin? (or does that have another use that my google search isn't coming up with?)
This is possible, but it would be a much larger change to the system. To take a particular example, look at /etc/shadow.
It needs to be protected against attackers, so it should not be owned by root - let's make it owned by "adm", say.
On the other hand, passwd(1) should be able to modify it, so passwd(1) should be set-uid "adm", not "root".
On the other hand, PAM pretty strongly assumes that is is running as root - it is full of setuid() and other system calls that are root-only, and arbitrary PAM modules may, and often do, assume that they are running as root, therefore passwd(1) should be set-uid "root".
See the problem? Mirek
2010/12/21 Miloslav Trmač:
If an attacker were controlling a process running with uid 0 and no capabilities at all, and /bin/sh were 0555, nothing prevents the attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes any attempts to change the file permissions rather pointless.
You don't even need to change permissions for root to be able to delete or change the contents of the directory.
Dick
I know that you're not proposing this, but can I just interject that if you make any of these files unreadable by 'other', then supermin appliance building will break.
http://libguestfs.org/febootstrap.8.html#supermin_appliances
I think supermin appliances are a sufficiently useful mechanism to generate virtual machines / cgroups roots on the fly that we shouldn't break it.
Rich.
tis 2010-12-21 klockan 11:47 -0500 skrev Colin Walters:
"But they still have uid 0, which typical system installation allows root to do things. For example, /bin/sh is 0755 and /bin is also 0755 perms. A disarmed root process can still trojan a system. But what if we got rid of all the read/write permissions for root?"
Eh? A process given capabilities via file capablities do not need to run with uid 0. It can run as the calling user (no setuid bit), and is what RemoveSETUID is about.
For things started as root, a capabilities aware system service started as root can drop to a non-root user while keeping the capabilities it needs. But this is not using file capabilities. But practicaly nothing accessed bu users should be running as root.
Regards Henrik
tis 2010-12-21 klockan 18:52 -0500 skrev i.grok@comcast.net:
Ok, so who says that the files must be owned by root? Make them owned by some other user -- say, bin? (or does that have another use that my google search isn't coming up with?)
Better to make the process not run as root imho.
Regards Henrik
ons 2010-12-22 klockan 00:59 +0100 skrev Miloslav Trmač:
This is possible, but it would be a much larger change to the system. To take a particular example, look at /etc/shadow.
It needs to be protected against attackers, so it should not be owned by root - let's make it owned by "adm", say.
Imho in that specific case it should be protected by two group acls. One group for writing/modifying, another for reading.
No need for capabilities at all, just setgroupid and file acls. shadow have no special significance to kernel functions.
Regards Henrik
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Andreas Schwab -
Colin Walters -
Daniel J Walsh -
Daniel P. Berrange -
Dick Tayter -
Henrik Nordström -
James Antill -
Jason L Tibbitts III -
Joe Nall -
John Poelstra -
Karel Zak -
Kevin Fenzi -
Lennart Poettering -
Matthew Miller -
Miloslav Trmač -
Panu Matilainen -
Patrick Monnerat -
Paul Howarth -
Pekka Pietikäinen -
Rahul Sundaram -
Richard W.M. Jones -
Scott Schmit -
Toshio Kuratomi