Re: vala 0.11 broke shotwell build in rawhide
On Thu, Jan 06, 2011 at 08:03:20AM +0530, Siddhesh Poyarekar wrote: > On Wed, Jan 05, 2011 at 07:31:13PM +, Peter Robinson wrote: > > Well as vala generates C code the current version should continue to > > function until shotwell 0.9.x comes out and adds support for the newer > > vala and it can be compiled or a patch appears in head that we can > > apply to 0.8.x > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=667490 > > > > I already have a patch; see the bugzilla above. The problem is that the > patch crashes vala. > Ahh, please ignore this. I saw your comment on the bugzilla now. Is there any documentation that describes these API changes? valadoc.org seems to have vala 0.10.x related documentation. -- Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vala 0.11 broke shotwell build in rawhide
On Wed, Jan 05, 2011 at 07:31:13PM +, Peter Robinson wrote: > Well as vala generates C code the current version should continue to > function until shotwell 0.9.x comes out and adds support for the newer > vala and it can be compiled or a patch appears in head that we can > apply to 0.8.x > > > https://bugzilla.redhat.com/show_bug.cgi?id=667490 > I already have a patch; see the bugzilla above. The problem is that the patch crashes vala. -- Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] MySQL 5.5 coming soon to rawhide
Jon Ciesla writes: > So should simply patching to call mysql_thread_end instead should do the > trick? Right. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Local system security
On Wed, 05 Jan 2011 16:13:25 -0500 Adam Jackson wrote: > But prevention of DoS on the part of local actors is just not a game you > can win. If nothing else, remember that the way Linux implements > malloc() assumes you have infinite memory, which means you overcommit > resources, which means failure happens. As long as we say things like the first one, Oracle will continue to pretend that Solaris is somehow more suitable to deploy Sunray... As for the second one, look here (we ship with overcommit set to heuristic, which is Webkit crashes in Rawhide): https://bugzilla.redhat.com/show_bug.cgi?id=648319#c63 -- Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
On Wed, 05.01.11 16:47, Adam Jackson (a...@redhat.com) wrote: > On Wed, 2011-01-05 at 16:33 -0500, Matt McCutchen wrote: > > On Wed, 2011-01-05 at 15:25 -0500, Adam Jackson wrote: > > > I don't have any of those. If the X server is running as root (like in > > > the gdm case) then I can put the socket wherever I want. If it's Xvfb, > > > then where do I put this directory? $HOME ? Nope, might not be > > > there. /tmp/$USER ? Won't work if someone else mkdir'd /tmp/ajax > > > before I did. > > > > What about the XDG_RUNTIME_DIR (/var/run/user/$USER) from systemd? > > atropine:~% ssh 10.16.61.101 > t...@10.16.61.101's password: > Last login: Wed Jan 5 16:42:43 2011 > [t...@dhcp-10-16-61-101 ~]$ set | grep XDG > [t...@dhcp-10-16-61-101 ~]$ rpm -q systemd fedora-release > systemd-15-1.fc15.x86_64 > fedora-release-15-0.3.noarch > > Console login at least gives me an XDG_SESSION_COOKIE. That should work. Probably during upgrade the PAM files weren't corrected. Try invoking "authconfig". XDG_SESSION_COOKIE is supposed to be secret and is probably going to go away soonishly, as it is obsolete now that we have /proc/self/loginuid. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for MicroNext MN-WD550M Wireless USB 2.0 Adaptor
On Wed, Jan 5, 2011 at 10:51 PM, Richard wrote: > On Wed, Jan 05, 2011 at 10:29:44PM +, mike cloaked wrote: >> I was recently testing an f14 install on an old laptop without wifi >> hardware - so I bought a small usb wifi adapter (MicroNext MN-WD550M >> Wireless USB 2.0 Adaptor) and this is recognised when plugged in: >> Bus 001 Device 002: ID 0bda:8171 Realtek Semiconductor Corp. RTL8188SU >> 802.11n WLAN Adapter >> >> However it was clear that there was no driver support for this device >> in the kernel. > > See drivers/staging/rtl8192su/r8192U_core.c, did you try that? > > Richard Thanks - I was not aware of this - will try when I get some time over the next few days -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Support for MicroNext MN-WD550M Wireless USB 2.0 Adaptor
On Wed, Jan 05, 2011 at 10:29:44PM +, mike cloaked wrote: > I was recently testing an f14 install on an old laptop without wifi > hardware - so I bought a small usb wifi adapter (MicroNext MN-WD550M > Wireless USB 2.0 Adaptor) and this is recognised when plugged in: > Bus 001 Device 002: ID 0bda:8171 Realtek Semiconductor Corp. RTL8188SU > 802.11n WLAN Adapter > > However it was clear that there was no driver support for this device > in the kernel. See drivers/staging/rtl8192su/r8192U_core.c, did you try that? Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: help with dist-git
Yesterday Roland McGrath said: >> But then that breaks simple things that (mostly) worked with the old >> cvs/Makefile system. >> >>fedpkg prep >>Traceback (most recent call last): >> ... >>git.errors.GitCommandError: 'git config --get branch.resurrect.merge' >> returned exit status 1: > > Do something like: > > git config --add branch.resurrect.merge refs/heads/f14/master > > to make fedpkg build for f14, or refs/heads/master for rawhide. Yes, that works just fine after jumping onto a local branch, thanks! > 'fedpkg switch-branch' is a front-end command that does this magic for you, > but I don't know exactly how it translates into the underlying git commands, > so I don't have a recipe. No, it appears this is only an alternate way of running the 'git checkout' after creating the local branch. The 'git config --add' hack is still needed. ../C -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Support for MicroNext MN-WD550M Wireless USB 2.0 Adaptor
I was recently testing an f14 install on an old laptop without wifi hardware - so I bought a small usb wifi adapter (MicroNext MN-WD550M Wireless USB 2.0 Adaptor) and this is recognised when plugged in: Bus 001 Device 002: ID 0bda:8171 Realtek Semiconductor Corp. RTL8188SU 802.11n WLAN Adapter However it was clear that there was no driver support for this device in the kernel. There is a Realtek driver available at: http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=48&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true#RTL8188SU I downloaded the linux driver version 2.6.6.0 from 2010/12/17 and untarred the files - and then used the standard make/make install to build. This works nicely. The question I have is whether there is likely to be any upstream FOSS support for this very neat little wireless adapter so that it becomes plug and play in the future? Is this being developed or is it all proprietary? Thanks -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
On Wed, 2011-01-05 at 16:37 -0500, Daniel J Walsh wrote: > [XDG_RUNTIME_DIR] does not exist until after the User has logged in. X > starts before > the user logs in. Also multiple users need to be able to talk to same > xserver. On Wed, 2011-01-05 at 16:47 -0500, Adam Jackson wrote: > atropine:~% ssh 10.16.61.101 > t...@10.16.61.101's password: > Last login: Wed Jan 5 16:42:43 2011 > [t...@dhcp-10-16-61-101 ~]$ set | grep XDG > [t...@dhcp-10-16-61-101 ~]$ rpm -q systemd fedora-release > systemd-15-1.fc15.x86_64 > fedora-release-15-0.3.noarch > > Console login at least gives me an XDG_SESSION_COOKIE. Yes, I guess XDG_RUNTIME_DIR won't work in its current form, but it should be easy enough for systemd to provide directories with the necessary permissions at the necessary times. I think this is the right solution. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Local system security
On Wed, 2011-01-05 at 16:13 -0500, Adam Jackson wrote: > On Wed, 2011-01-05 at 14:10 -0500, Matt McCutchen wrote: > > On Wed, 2011-01-05 at 11:12 -0500, Adam Jackson wrote: > > > (And of course what we're doing here is protecting against a malicious > > > attacker who already has enough privileges to run code on your system, > > > which means you're pretty far into having already lost. Meh.) > > > > I've seen this viewpoint a number of places. IMO, it's a shame that the > > community seems to be giving up on local system security. In various > > situations, it would be quite convenient if I could give other people > > shell accounts on my machine without risking compromise of all of my > > data. The virtualization solutions are more work to set up. > > You're putting words in my mouth just a little. > > The existing discussion was about denial of service attacks. OK, I misunderstood. Reading your remark by itself, I thought it referred to confidentiality and integrity too. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
On Wed, 2011-01-05 at 16:33 -0500, Matt McCutchen wrote: > On Wed, 2011-01-05 at 15:25 -0500, Adam Jackson wrote: > > I don't have any of those. If the X server is running as root (like in > > the gdm case) then I can put the socket wherever I want. If it's Xvfb, > > then where do I put this directory? $HOME ? Nope, might not be > > there. /tmp/$USER ? Won't work if someone else mkdir'd /tmp/ajax > > before I did. > > What about the XDG_RUNTIME_DIR (/var/run/user/$USER) from systemd? atropine:~% ssh 10.16.61.101 t...@10.16.61.101's password: Last login: Wed Jan 5 16:42:43 2011 [t...@dhcp-10-16-61-101 ~]$ set | grep XDG [t...@dhcp-10-16-61-101 ~]$ rpm -q systemd fedora-release systemd-15-1.fc15.x86_64 fedora-release-15-0.3.noarch Console login at least gives me an XDG_SESSION_COOKIE. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Local system security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/05/2011 04:38 PM, Gregory Maxwell wrote: > On Wed, Jan 5, 2011 at 4:13 PM, Adam Jackson wrote: >> But prevention of DoS on the part of local actors is just not a game you >> can win. If nothing else, remember that the way Linux implements >> malloc() assumes you have infinite memory, which means you overcommit >> resources, which means failure happens. You can write code that > [snip] > > # echo 2 > /proc/sys/vm/overcommit_memory > # echo 0 > /proc/sys/vm/overcommit_ratio > > :) > > (and good luck with that!) BTW SELinux confined users and cgroups can help somewhat control those nasty students, but stopping a DOS will still be difficult. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0k5r8ACgkQrlYvE4MpobNkVgCgn1WVRz2Hh+SfFJpGRm9uAPNR gSoAniwmk0GOsK4igotX08b/MgnBqhqa =EFCr -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Local system security
On Wed, Jan 5, 2011 at 4:13 PM, Adam Jackson wrote: > But prevention of DoS on the part of local actors is just not a game you > can win. If nothing else, remember that the way Linux implements > malloc() assumes you have infinite memory, which means you overcommit > resources, which means failure happens. You can write code that [snip] # echo 2 > /proc/sys/vm/overcommit_memory # echo 0 > /proc/sys/vm/overcommit_ratio :) (and good luck with that!) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/05/2011 04:33 PM, Matt McCutchen wrote: > On Wed, 2011-01-05 at 15:25 -0500, Adam Jackson wrote: >> On Wed, 2011-01-05 at 13:38 -0500, Matt McCutchen wrote: >>> The >>> more significant DoS condition is another user taking the name you want, >>> which can happen in the abstract namespace but not in a directory only >>> you can write. >> >> I don't have any of those. If the X server is running as root (like in >> the gdm case) then I can put the socket wherever I want. If it's Xvfb, >> then where do I put this directory? $HOME ? Nope, might not be >> there. /tmp/$USER ? Won't work if someone else mkdir'd /tmp/ajax >> before I did. > > What about the XDG_RUNTIME_DIR (/var/run/user/$USER) from systemd? > This does not exist until after the User has logged in. X starts before the user logs in. Also multiple users need to be able to talk to same xserver. Not sure about switchuser. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0k5IEACgkQrlYvE4MpobPAYwCcD1bnU+qES3uv/tc/7Jw3jlwD SQMAoJf+5uXZ2FkN2vLOOuiWLWojKSkB =OpVt -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal to improve the Sponsorship process on Fedora
> "JS" == Jochen Schmitt writes: JS> because I have read, that new contributors should not applies JS> membership on the packagers group and the sponsor should invites JS> them to this group, Well, nobody can apply to the packager group; it is invite-only. There may be a few people in the sponsorship queue from before the invite-only functionality was implemented. If I understand your proposal, you simply dislike that adding someone to a group involves typing their FAS ID into the "add to group" box and then clicking the sponsor link, and you'd prefer to bypass the second step? I suppose I can see the point, although the issue seems awfully minor to me. Did you have a patch implementing this? - J< -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
On Wed, 2011-01-05 at 15:25 -0500, Adam Jackson wrote: > On Wed, 2011-01-05 at 13:38 -0500, Matt McCutchen wrote: > > The > > more significant DoS condition is another user taking the name you want, > > which can happen in the abstract namespace but not in a directory only > > you can write. > > I don't have any of those. If the X server is running as root (like in > the gdm case) then I can put the socket wherever I want. If it's Xvfb, > then where do I put this directory? $HOME ? Nope, might not be > there. /tmp/$USER ? Won't work if someone else mkdir'd /tmp/ajax > before I did. What about the XDG_RUNTIME_DIR (/var/run/user/$USER) from systemd? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 664360] Rebase on upstream version 4.0
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=664360 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-XML-TreeBuilder-4.0-3. ||fc14 Resolution||ERRATA Last Closed||2011-01-05 16:23:37 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 664360] Rebase on upstream version 4.0
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=664360 --- Comment #4 from Fedora Update System 2011-01-05 16:23:32 EST --- perl-XML-TreeBuilder-4.0-3.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Local system security
On Wed, 2011-01-05 at 14:10 -0500, Matt McCutchen wrote: > On Wed, 2011-01-05 at 11:12 -0500, Adam Jackson wrote: > > (And of course what we're doing here is protecting against a malicious > > attacker who already has enough privileges to run code on your system, > > which means you're pretty far into having already lost. Meh.) > > I've seen this viewpoint a number of places. IMO, it's a shame that the > community seems to be giving up on local system security. In various > situations, it would be quite convenient if I could give other people > shell accounts on my machine without risking compromise of all of my > data. The virtualization solutions are more work to set up. You're putting words in my mouth just a little. The existing discussion was about denial of service attacks. The case I was making is that adequate defense against DoS requires programming techniques more subtle than simple prohibition of abstract sockets, and (more broadly) a system that assures that resources are fairly allocated, for arbitrarily complex definitions of "fair". If you have a malicious user who can run code on your machine, you've granted him CPU time. You have already lost. You're deciding how much to lose. The position you're painting me in is in opposition to: "[...] risking compromise of all my data [...]" and at no point was I arguing that access control or integrity were unimportant. If they weren't, we wouldn't bother with xauth at all. And they are concepts that are entirely achievable even within the unix model. You're still relying on the absence of bugs, but okay, that's always the gamble we make. But prevention of DoS on the part of local actors is just not a game you can win. If nothing else, remember that the way Linux implements malloc() assumes you have infinite memory, which means you overcommit resources, which means failure happens. You can write code that prevents many DoS conditions and that's almost always worthwhile, but at the end of the day it's a system with overcommit and therefore you either need trust in your participants or policy to rein them in. DoS simply is not a security issue. There are many other adjectives you can apply to it - availability, reliability, quality, usability; desirable qualities all - but security is not one of them. > If what > you say is right, the many schools that still use large shared shell > servers are relying on their users not to be too evil, or alternatively > the users shouldn't use the servers for anything important. That's been true since at least the RTM worm. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Proposal to improve the Sponsorship process on Fedora
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, because I have read, that new contributors should not applies membership on the packagers group and the sponsor should invites them to this group, I have create the following proposal to improve the sponsorship process on Fedora: https://fedoraproject.org/wiki/User:S4504kr/SponsorshipImprovement Best Regards: Jochen Schmitt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iJwEAQECAAYFAk0k3rwACgkQZLAIBz9lVu/w5AP8CJ1b0QWqmziRzJ/BSRh/nhST /BW48Yf0Xv3qR8v8BWjixL7a4PJPiWagB74NvVRKc0/RalmmtvguH24nUG41ZgrM U/WVw7hemQN2AP2zLeWVGLfjYtdjmUxE3Zh6knD8ZWGa1TzpeF2WylBvGHgYiUQM OBjcd008iyZTSkJOm0k= =sXrZ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
On Wed, 2011-01-05 at 13:38 -0500, Matt McCutchen wrote: > On Wed, 2011-01-05 at 11:12 -0500, Adam Jackson wrote: > > The deeper problem is that clients authenticate themselves to the > > server, but then simply trust that the server is the server they were > > hoping for. If you don't have a process tree relationship (like the gdm > > +displayfd case) then you have to go all the way to something like > > Kerberos for that kind of bidirectional auth. > > Not quite: you can use the xauth cookie as a pre-shared key. That doesn't work. If you're trying to spoof the X server then you write an X server that simply accepts whatever auth cookie you give it. There's no way, once you've connected to X, to ask what cookies it accepts. (Because different auth cookies can have different security levels, so you don't want to disclose to a less-trusted level the cookie of a more-trusted level.) The only way you can know what cookies it accepts is if you started it yourself; and if you did that, you have a process tree relationship. > > and indeed, has _more_ DoS > > conditions than abstract sockets since they don't get garbage-collected > > on system crash > > They do if you use a tmpfs (e.g., /var/run with systemd), but in any > event it's easy enough to unlink the socket or try another name. Your attacker wants to spoof a service. They've created a socket on the name you want, and now you want to unlink it and make your own. Why do you think they can't notice the unlink and recreate the socket? Thus making it a race you might win sometimes, depending on how the scheduler is feeling on any given day. > The > more significant DoS condition is another user taking the name you want, > which can happen in the abstract namespace but not in a directory only > you can write. I don't have any of those. If the X server is running as root (like in the gdm case) then I can put the socket wherever I want. If it's Xvfb, then where do I put this directory? $HOME ? Nope, might not be there. /tmp/$USER ? Won't work if someone else mkdir'd /tmp/ajax before I did. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld - A firewall daemon with D-BUS interface providing a dynamic firewall (test version)
On Wed, Jan 05, 2011 at 01:29:51PM +, Daniel P. Berrange wrote: > -p 0x8035 -j I-vnet0-rarp Who still uses RARP? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vala 0.11 broke shotwell build in rawhide
On Wed, Jan 5, 2011 at 6:51 PM, Siddhesh Poyarekar wrote: > Hi, > > The upstream shotwell does not build with vala 0.11.* since there are > a bunch of incompatible changes between vala-0.10.x and 0.11.x. Is > there a plan to have a parallel installable vala-0.10.x in > rawhide/f15? I was looking at that today as well. From what I can see 0.11.x is needed for gtk3 / libnotify 0.7 and other gnome 3 changes so I think we're stuck which ever way. > I can't see any other way to get shotwell built. I tried making > changes to shotwell-0.8.0 code to get it to build with vala, but in > the end the vala compiler ends up crashing. Bug report here: Well as vala generates C code the current version should continue to function until shotwell 0.9.x comes out and adds support for the newer vala and it can be compiled or a patch appears in head that we can apply to 0.8.x > https://bugzilla.redhat.com/show_bug.cgi?id=667490 Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes for today's FESCo meeting (2011-01-05)
=== #fedora-meeting: FESCO (2011-01-05) === Meeting started by nirik at 17:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-01-05/fesco.2011-01-05-17.30.log.html Meeting summary --- * init process (nirik, 17:30:01) * #516 Updates policy adjustments/changes (nirik, 17:40:30) * AGREED: will allow direct pushes for security updates that are not critpath. (nirik, 17:43:12) * #518 Abrt (nirik, 17:45:18) * will ask abrt maintainers for a roadmap (nirik, 17:47:39) * will see about a session at fudcon to try and improve abrt. (nirik, 17:47:51) * #521 Reconsider RemoveSUID feature (nirik, 17:51:03) * LINK: https://fedorahosted.org/fesco/ticket/521 (nirik, 18:07:18) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=648653 (dwalsh, 18:07:31) * LINK: http://forums.grsecurity.net/viewtopic.php?f=7&t=2522 (dwalsh, 18:08:04) * AGREED: will gather more info and revisit this next week. (nirik, 18:21:33) * need info on tmpfs status (nirik, 18:21:40) * need info on nfs capabilities status. (nirik, 18:21:48) * #526 "systemd" feature scope acurracy and precision (nirik, 18:22:15) * AGREED: mitr and mezcalero to work on updating feature page. (nirik, 18:42:33) * #527 Dist Git Branch Redux Proposal (nirik, 18:42:53) * AGREED: This proposal is accepted. (nirik, 18:46:09) * #528 Add xz package to buildsys-build comps group (nirik, 18:46:18) * AGREED: This proposal is accepted. (nirik, 18:47:02) * #532 Nonresponsive maintainer: pysvn (nirik, 18:47:09) * AGREED: will add reporter as co-maintainer (nirik, 18:50:45) * #531 Orphaned package ownership claiming clarification (nirik, 18:50:54) * #531 Orphaned package ownership claiming clarification (nirik, 18:51:33) * AGREED: ask pkgdb/releng folks about setting up something to auto retire/block packages after 3 months as orphan. (nirik, 19:03:04) * #434 F15Feature - DNSSEC_on_workstations - https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations (nirik, 19:03:24) * will ask for updated info from feature owners. (nirik, 19:05:01) * #529 F15Feature: KDE46 - http://fedoraproject.org/wiki/Features/KDE46 (nirik, 19:05:09) * AGREED: feature is approved. (nirik, 19:06:41) * #530 F15Feature: Riak - http://fedoraproject.org/wiki/Features/Riak (nirik, 19:06:55) * AGREED: Feature is approved (nirik, 19:08:53) * #534 F15Feature: Dynamic Firewall -https://fedoraproject.org/wiki/Features/DynamicFirewall (nirik, 19:08:59) * AGREED: Feature is approved. (nirik, 19:20:02) * #537 F15Feature: Spice support for virt-manager - http://fedoraproject.org/wiki/Features/SpiceInVirtManager (nirik, 19:20:11) * AGREED: Feature is approved. (nirik, 19:20:55) * #535 F15Feature: ecryptfs in authconfig - http://fedoraproject.org/wiki/Features/EcryptfsAuthConfig (nirik, 19:21:05) * AGREED: Feature is approved. (nirik, 19:24:19) * #536 F15Feature: RPM 4.9 - http://fedoraproject.org/wiki/Features/RPM4.9 (nirik, 19:24:21) * AGREED: Feature is approved. (nirik, 19:25:59) * Open Floor (nirik, 19:26:10) Meeting ended at 19:28:20 UTC. People Present (lines said) --- * nirik (203) * cwickert (60) * mjg59 (57) * ajax (31) * notting (31) * zodbot (23) * mezcalero (19) * dwalsh (17) * sgrubb (16) * tibbs|h (13) * SMParrish_mobile (11) * mitr (10) * mmaslano (9) * skvidal (5) * rbergeron (2) * dgilmore (2) * pjones (1) * fenris02 (1) * drago01 (1) * kylem (0) * mclasen (0) * SMParrish (0) -- 17:30:01 #startmeeting FESCO (2011-01-05) 17:30:01 Meeting started Wed Jan 5 17:30:01 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:30:01 #meetingname fesco 17:30:01 The meeting name has been set to 'fesco' 17:30:01 #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 17:30:01 #topic init process 17:30:01 Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting 17:30:37 fuck fuck fuck 17:30:39 sorry 17:30:54 the meeting is just to early for me :) 17:31:08 sorry. ;( 17:31:10 Hi 17:31:14 we could revisit times again... 17:31:29 * cwickert will be around in 5 minutes 17:31:37 I think we can wait 5 minutes 17:31:43 * notting is here 17:31:44 thanks 17:31:56 I am here but mobile :) 17:32:07 * mmaslano is here 17:32:42 hey hey\ 17:33:50 shall we wait a few before starting for cwickert... 17:34:10 sure 17:34:30 i may have to duck out around 1, apologies 17:35:51 no worries. we have a bunch of features today, but hopefully we can churn thru them pretty fast. 17:37:44 hopefully everyone had a nice holiday. ;) 17:38:06 * cwickert is back 17:38:16 cool. Shall we dive in then? 17:38:45 sure, but again I haven't found the time to work on the updates-feature
Re: [HEADS-UP] MySQL 5.5 coming soon to rawhide
Tom Lane wrote:
> Jon Ciesla writes:
>
>> Tom Lane wrote:
>>
>>> I got tired of the amount of visible churn in exported-symbols-you're-
>>> not-supposed-to-use. The new release will use a linker --version-script
>>> to hide everything except the documented API functions. This might
>>> break any apps that are relying on non-API functions. If so, I'm
>>> willing to consider on a case-by-case basis whether to add those symbols
>>> back to the ABI or fix the callers.
>>>
>
>
>> Is the following a MySQL issue or a Bacula issue?
>>
>
>
>> /builddir/build/BUILD/bacula-5.0.3/bacula-mysql/src/cats/mysql.c:295:
>> undefined reference to `my_thread_end'
>>
>
> Well, it's certainly a byproduct of that change. So far as I can find,
> mysql_thread_end is a documented part of the API and my_thread_end is
> not. Is there a good reason for Bacula to be calling the latter?
>
> A quick look into the mysql sources finds
>
> void STDCALL mysql_thread_end()
> {
> #ifdef THREAD
> my_thread_end();
> #endif
> }
>
> which makes it look like the correct answer is "no" ...
>
> regards, tom lane
>
So should simply patching to call mysql_thread_end instead should do the
trick?
-J
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Local system security
An aside: On Wed, 2011-01-05 at 11:12 -0500, Adam Jackson wrote: > (And of course what we're doing here is protecting against a malicious > attacker who already has enough privileges to run code on your system, > which means you're pretty far into having already lost. Meh.) I've seen this viewpoint a number of places. IMO, it's a shame that the community seems to be giving up on local system security. In various situations, it would be quite convenient if I could give other people shell accounts on my machine without risking compromise of all of my data. The virtualization solutions are more work to set up. If what you say is right, the many schools that still use large shared shell servers are relying on their users not to be too evil, or alternatively the users shouldn't use the servers for anything important. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
vala 0.11 broke shotwell build in rawhide
Hi, The upstream shotwell does not build with vala 0.11.* since there are a bunch of incompatible changes between vala-0.10.x and 0.11.x. Is there a plan to have a parallel installable vala-0.10.x in rawhide/f15? I can't see any other way to get shotwell built. I tried making changes to shotwell-0.8.0 code to get it to build with vala, but in the end the vala compiler ends up crashing. Bug report here: https://bugzilla.redhat.com/show_bug.cgi?id=667490 -- Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
On Wed, 2011-01-05 at 11:12 -0500, Adam Jackson wrote: > The deeper problem is that clients authenticate themselves to the > server, but then simply trust that the server is the server they were > hoping for. If you don't have a process tree relationship (like the gdm > +displayfd case) then you have to go all the way to something like > Kerberos for that kind of bidirectional auth. Not quite: you can use the xauth cookie as a pre-shared key. > Simply moving back to > filesystem sockets does not solve that - Right; what solves it is putting the socket in a place that is writable only by the user running the server. > and indeed, has _more_ DoS > conditions than abstract sockets since they don't get garbage-collected > on system crash They do if you use a tmpfs (e.g., /var/run with systemd), but in any event it's easy enough to unlink the socket or try another name. The more significant DoS condition is another user taking the name you want, which can happen in the abstract namespace but not in a directory only you can write. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20110105 changes
Slowly working my way through these (thanks also Orion Poplawski for doing a couple of builds). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: firewalld - A firewall daemon with D-BUS interface providing a dynamic firewall (test version)
On Thu, Dec 23, 2010 at 05:03:56PM +0100, Thomas Woerner wrote: > Hello, > > as discussed some time ago, I worked on the proof of concept > implementation of firewalld. FirewallD is a service daemon with a D-BUS > interface that provides a dynamic managed firewall. > > For more information on firewalld, please have a look at: > https://fedoraproject.org/wiki/FirewallD/ > > About this version: > > This is mostly the proof of concept implementation with some changes and > is feature complete for F-15 as a firewalld preview version. It will not > be enabled per default and will also not get installed per default. The > system-config-firewall with static firewall model will still be the > default firewall solution for Fedora 15. > > What this firewalld version can do: > > - It supports most of the firewall features system-config-firewall had, >but there are three limitations: > >1) custom firewall rule files (iptables save format) are not > supported and most likely will never be, but there is support for > custom rules (limited functionality). > >2) sysctl changes for ip_forward are not done, yet. > >3) There are no permanent firewall settings, this means that all > settings are lost after a service restart or reboot. Permanent > firewall settings will be added later on. Lack of persistence across reboots isn't a problem for libvirt needs, but we would expect even non-persistent rules to survive a restart of the firewalld process. Currently everything is torn down when firewalld stops, so if you need todo a 'service firewalld restart' in an RPM postscript during RPM upgrades, then you will interrupt traffic to/from guests, or temporarily open security holes in the network filtering of guests. Thus, the teardown and setup of firewall rules must be decoupled from the firewalld process startup/shutdown lifecycle, to allow restarts of firewalld without causing a security weakness/service interruption. > - There is an rule and chain interface for libvirt, but the PolicyKit >policy is not in place, yet. Looking at the dbus API this appears to let me add/remove/query rules in the INPUT_libvirt, OUTPUT_libvirt FORWARD_libvirt chains, but AFAICT it doesn't yet provide any way to create additional chains. eg, the setup we need for libvirt has chains linked quite a few levels deep. Chain: PREROUTING_libvirt -i vnet0 -j libvirt-I-vnet0 -i vnet1 -j libvirt-I-vnet1 -i vnet2 -j libvirt-I-vnet2 ... Chain: libvirt-I-vnet0 -p IPv4 -j I-vnet0-ipv4 -p ARP -j I-vnet0-arp -p 0x8035 -j I-vnet0-rarp -p 0x835 -j ACCEPT -j DROP Chain: I-vnet0-ipv4 Chain: I-vnet0-arp Chain: I-vnet0-rarp And so on for vnet1, vnet2, and more Also, the naming of the extra chains needs to be completely controlled by libvirt with no extra prefix added by firewalld. This is because the iptables kernel chain name length limit is very short and thus we need to use every byte available :-( Regards, Daniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
On Wed, 2011-01-05 at 13:52 +0100, Lennart Poettering wrote: > That's precisely what I want to tell people: don't use the abstract > socket namespace, unless you really know what you do. The only cases > where it really makes sense to use it is if you have a privileged > service that i sstarted before any user code and never goes away and > hence is not vulnerable to these problems. The D-Bus system bus, the > init systemd and udev are probably the only ones really qualifying for > that. Everything else is restartable. Fedora's X has a patch [1] (which I'm almost certain has been posted upstream, and certainly sounded like it had approval at the most recent XDS when it came up) where the X server will simply _pick_ a (set of) display socket(s) not already bound, and tell you what it picked on a file descriptor you pass in from the launching process. Which neatly avoids this kind of DoS, and also eliminates the failure case in gdm that causes the display seizure of doom when X fails to start for other reasons. Right now the only thing using this is the selinux X sandbox, but it's certainly generally applicable. The deeper problem is that clients authenticate themselves to the server, but then simply trust that the server is the server they were hoping for. If you don't have a process tree relationship (like the gdm +displayfd case) then you have to go all the way to something like Kerberos for that kind of bidirectional auth. Simply moving back to filesystem sockets does not solve that - and indeed, has _more_ DoS conditions than abstract sockets since they don't get garbage-collected on system crash - so simply proscribing the use of abstract sockets seems a little harsh. (And of course what we're doing here is protecting against a malicious attacker who already has enough privileges to run code on your system, which means you're pretty far into having already lost. Meh.) [1] - http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-server.git;a=blob_plain;f=xserver-1.6.0-displayfd.patch;hb=HEAD - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
On Wed, 2011-01-05 at 16:35 +0100, Lennart Poettering wrote: > On Wed, 05.01.11 09:39, Matt McCutchen (m...@mattmccutchen.net) wrote: > > > > That's precisely what I want to tell people: don't use the abstract > > > socket namespace, unless you really know what you do. The only cases > > > where it really makes sense to use it is if you have a privileged > > > service that i sstarted before any user code and never goes away and > > > hence is not vulnerable to these problems. > > > > But as I said, it's impossible to guarantee that the service never goes > > away. It could crash or get OOM-killed (or terminate before all > > potential clients have terminated during system shutdown: is that > > possible?), and then you have a security hole. So I would recommend > > filesystem sockets for everything. > > Well, if PID 1 terminates the kernel halts the system. Valid point. > And udev fiddles with its OOM score to avoid being killed. There could still be a bug that causes udev to crash. As a general principle, systems should fail secure. > And if the dbus system bus > goes away the system becomes kinda unusable too. Whether system features break for legitimate users is beside the point. As long as user applications are still running, they may connect to the system bus and be tricked into doing something harmful by an attacker who impersonates it. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
On Wed, 05.01.11 09:39, Matt McCutchen (m...@mattmccutchen.net) wrote: > > That's precisely what I want to tell people: don't use the abstract > > socket namespace, unless you really know what you do. The only cases > > where it really makes sense to use it is if you have a privileged > > service that i sstarted before any user code and never goes away and > > hence is not vulnerable to these problems. > > But as I said, it's impossible to guarantee that the service never goes > away. It could crash or get OOM-killed (or terminate before all > potential clients have terminated during system shutdown: is that > possible?), and then you have a security hole. So I would recommend > filesystem sockets for everything. Well, if PID 1 terminates the kernel halts the system. And udev fiddles with its OOM score to avoid being killed. And if the dbus system bus goes away the system becomes kinda unusable too. These three services are kinda essential, if they go away the system is dead. And given that this is how it is, these three are most likely the only ones where it is safe that they use abstract namespace sockets. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
On Wed, 2011-01-05 at 13:52 +0100, Lennart Poettering wrote: > On Tue, 04.01.11 21:31, Matt McCutchen (m...@mattmccutchen.net) wrote: > > > On Tue, 2011-01-04 at 14:11 +0100, Lennart Poettering wrote: > > > Of these being used, dbus is correctly implemented, since it randomizes > > > the socket name. Same for gdm. > > > > The relevant point is not randomness or unguessability, but that dbus > > chooses an available name and passes the actual name being used to > > clients (via the DBUS_SESSION_BUS_ADDRESS environment variable). > > > > However, even this may not be enough if the session dbus-daemon dies for > > any reason and an attacker takes over the name and sends malicious > > responses. It would be preferable if process death cases (the > > OOM-killer, even) did not automatically become security holes. I'm not > > sure how best to solve this. Wean ourselves from the convenience of the > > abstract namespace and go back to filesystem sockets in places only > > writable by appropriate parties? > > That's precisely what I want to tell people: don't use the abstract > socket namespace, unless you really know what you do. The only cases > where it really makes sense to use it is if you have a privileged > service that i sstarted before any user code and never goes away and > hence is not vulnerable to these problems. But as I said, it's impossible to guarantee that the service never goes away. It could crash or get OOM-killed (or terminate before all potential clients have terminated during system shutdown: is that possible?), and then you have a security hole. So I would recommend filesystem sockets for everything. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: OCaml 3.12
On Tue, Jan 04, 2011 at 11:11:40PM +, Richard W.M. Jones wrote: > > https://fedoraproject.org/wiki/Features/OCaml3.12 > > Hopefully most packages will just rebuild. I'd welcome any PPs > who want to help out. Just a note: ocaml < 3.12.0-3 built but had incomplete dependencies. You need to check they get built against ocaml >= 3.12.0-3. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Security issues with abstract namespace sockets
On Tue, 04.01.11 21:31, Matt McCutchen (m...@mattmccutchen.net) wrote: > On Tue, 2011-01-04 at 14:11 +0100, Lennart Poettering wrote: > > Of these being used, dbus is correctly implemented, since it randomizes > > the socket name. Same for gdm. > > The relevant point is not randomness or unguessability, but that dbus > chooses an available name and passes the actual name being used to > clients (via the DBUS_SESSION_BUS_ADDRESS environment variable). > > However, even this may not be enough if the session dbus-daemon dies for > any reason and an attacker takes over the name and sends malicious > responses. It would be preferable if process death cases (the > OOM-killer, even) did not automatically become security holes. I'm not > sure how best to solve this. Wean ourselves from the convenience of the > abstract namespace and go back to filesystem sockets in places only > writable by appropriate parties? That's precisely what I want to tell people: don't use the abstract socket namespace, unless you really know what you do. The only cases where it really makes sense to use it is if you have a privileged service that i sstarted before any user code and never goes away and hence is not vulnerable to these problems. The D-Bus system bus, the init systemd and udev are probably the only ones really qualifying for that. Everything else is restartable. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning some packages
Hi all, Because of my studies, I have no more time to devote to packaging, so I'm orphaning the followings: gconf-cleaner - Upstream dead long time ago, 1 bug gnome-specimen - Upstream dead too, no bug qemu-launcher - Another upstream dead, no bug gtkperf - No more upstream, no bug, but still working fine skychart - Upstream alive, 3 bugs, have a co-maintainer (mmahut, do you want to be maintainer?) notecase - Upstream stopped devel, FTBS bug with a fixed package living in the F13 repo (I don't know what I have done here) wifi-radar - Upstream still alive, updated, 2 old bugs (including one RFE) Please let me know if you want to take ownership of one of them, I'll release it. If nobody wants them, I will retire the first three. Regards, Pablo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
