Fedora-ARM 12
Hi all, Fedora-ARM 12 is now available! The RFS is available at: http://ftp.linux.org.uk/pub/linux/arm/fedora/rootfs/rootfs-f12.tar.bz2 The following package groups are available: Base, Core, Base-X, GNOME-Desktop, XFCE-Desktop, Java, Java-Development, Admin-Tools, System-Tools, Web Server, and commonly used embedded packages. As usual it is built for ARMv5 EABI, soft-float, little endian. For more details head to: http://fedoraproject.org/wiki/Architectures/ARM Cheers, Kedar. -- fedora-announce-list mailing list fedora-announce-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list
Cooperative Bug Isolation for Fedora 12
The Cooperative Bug Isolation Project (CBI) is now available for Fedora 12. CBI (http://www.cs.wisc.edu/cbi/) is an ongoing research effort to find and fix bugs in the real world. We distribute specially modified versions of popular open source software packages. These special versions monitor their own behavior while they run, and report back how they work (or how they fail to work) in the hands of real users like you. Even if you've never written a line of code in your life, you can help make things better for everyone simply by using our special bug-hunting packages. We currently offer instrumented versions of Evolution, The GIMP, GNOME Panel, Gnumeric, Nautilus, Pidgin, Rhythmbox, and SPIM. Download at http://www.cs.wisc.edu/cbi/downloads/. We support PackageManager, yum, apt, and many other RPM updater tools; see http://www.cs.wisc.edu/cbi/downloads/repo-config.html for customized configuration help for any of our supported distributions and updater tools. Or just download and install http://www.cs.wisc.edu/cbi/downloads/rpm/fedora-12-i386/RPMS.tools/cbi-package-config-12-10.i686.rpm to automatically configure most popular RPM updaters to use the CBI repository. It's that easy! Tell your friends! Tell your neighbors! The more of you there are, the more bugs we can find. We still offer CBI packages for earlier releases as well, going all the way back to Fedora 1. When and if you decide to upgrade to Fedora 12, we'll be ready for you. Until then, your participation remains valuable even on older distributions. -- Dr. Ben, the CBI guy -- fedora-announce-list mailing list fedora-announce-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list
Re: Postgresql Database Error
On 11/18/2009 02:15 AM, peng chen wrote: hello, fedora-buildsys-list: when I requset a build task for pakcage anaconda to koji, one errie error come out. It detailed as follow: pg.DatabaseError: error ' ERROR: new row for relation task violates check constraint task_weight_check ' in ' UPDATE task SET weight=-0.9838856091396 WHERE id = 16296 ' I'm sure that the source rpm of anaconda is OK,because I succed to build it in local mock environment. and the repo is the same as the koji build server. hope you do me a favor sincerely! Does one of the builds have a completion_time earlier than its create_event time? Koji uses the build duration to dynamically calculate the weight of the task. It should probably be checking for a negative result, but it doesn't. -- Fedora-buildsys-list mailing list Fedora-buildsys-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Postgresql Database Error
On 11/18/2009 02:15 AM, peng chen wrote:
hello, fedora-buildsys-list:
when I requset a build task for pakcage anaconda to koji,
one errie error come out.
It detailed as follow:
pg.DatabaseError: error ' ERROR: new row for relation task violates
check constraint task_weight_check '
in ' UPDATE task SET weight=-0.9838856091396 WHERE id = 16296 '
I'm sure that the source rpm of anaconda is OK,because I succed to build
it in local mock environment. and
the repo is the same as the koji build server.
hope you do me a favor sincerely!
The system time on your hub must have been set back during an anaconda
build and there must be sufficiently few anaconda builds for this to
cause getAverageBuildDuration('anaconda') to return a negative number.
We should of course fix this, but you should also avoid rolling back the
time on your koji hosts, especially the hub and db hosts.
In the meantime, this patch should help
--- a/builder/kojid
+++ b/builder/kojid
@@ -2033,6 +2033,9 @@ class BuildArchTask(BaseTaskHandler):
avg = session.getAverageBuildDuration(name)
if not avg:
return
+if avg 0:
+self.logger.warn(Negative average build duration for %s:
%s, name, avg)
+return
# increase the task weight by 0.75 for every hour of build
duration
adj = (avg / 4800.0)
# cap the adjustment at +4.5
--
Fedora-buildsys-list mailing list
Fedora-buildsys-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
Re: Postgresql Database Error
2009/11/19 fedora-buildsys-list-requ...@redhat.com
Send Fedora-buildsys-list mailing list submissions to
fedora-buildsys-list@redhat.com
To subscribe or unsubscribe via the World Wide Web, visit
https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
or, via email, send a message with subject or body 'help' to
fedora-buildsys-list-requ...@redhat.com
You can reach the person managing the list at
fedora-buildsys-list-ow...@redhat.com
When replying, please edit your Subject line so it is more specific
than Re: Contents of Fedora-buildsys-list digest...
Today's Topics:
1. Postgresql Database Error (peng chen)
2. Re: Postgresql Database Error (Mike Bonnet)
3. Re: Postgresql Database Error (Mike McLean)
--
Message: 1
Date: Wed, 18 Nov 2009 15:15:46 +0800
From: peng chen peng.che...@gmail.com
Subject: Postgresql Database Error
To: fedora-buildsys-list@redhat.com
Message-ID:
7e200e7f0911172315q4b2fc425p8575bdd7e2b74...@mail.gmail.com
Content-Type: text/plain; charset=iso-8859-1
hello, fedora-buildsys-list:
when I requset a build task for pakcage anaconda to koji,
one errie error come out.
It detailed as follow:
pg.DatabaseError: error ' ERROR: new row for relation task violates
check constraint task_weight_check '
in ' UPDATE task SET weight=-0.9838856091396 WHERE id = 16296 '
I'm sure that the source rpm of anaconda is OK,because I succed to build
it in local mock environment. and
the repo is the same as the koji build server.
hope you do me a favor sincerely!
-- next part --
An HTML attachment was scrubbed...
URL:
https://www.redhat.com/archives/fedora-buildsys-list/attachments/20091118/b463b957/attachment.html
--
Message: 2
Date: Wed, 18 Nov 2009 08:51:54 -0500
From: Mike Bonnet mi...@redhat.com
Subject: Re: Postgresql Database Error
To: fedora-buildsys-list@redhat.com
Message-ID: 4b03fbfa.2000...@redhat.com
Content-Type: text/plain; charset=UTF-8
On 11/18/2009 02:15 AM, peng chen wrote:
hello, fedora-buildsys-list:
when I requset a build task for pakcage anaconda to koji,
one errie error come out.
It detailed as follow:
pg.DatabaseError: error ' ERROR: new row for relation task violates
check constraint task_weight_check '
in ' UPDATE task SET weight=-0.9838856091396 WHERE id = 16296 '
I'm sure that the source rpm of anaconda is OK,because I succed to
build
it in local mock environment. and
the repo is the same as the koji build server.
hope you do me a favor sincerely!
Does one of the builds have a completion_time earlier than its
create_event time? Koji uses the build duration to dynamically
calculate the weight of the task. It should probably be checking for a
negative result, but it doesn't.
--
Message: 3
Date: Wed, 18 Nov 2009 08:56:59 -0500
From: Mike McLean mi...@redhat.com
Subject: Re: Postgresql Database Error
To: fedora-buildsys-list@redhat.com
Message-ID: 4b03fd2b.5040...@redhat.com
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 11/18/2009 02:15 AM, peng chen wrote:
hello, fedora-buildsys-list:
when I requset a build task for pakcage anaconda to koji,
one errie error come out.
It detailed as follow:
pg.DatabaseError: error ' ERROR: new row for relation task
violates
check constraint task_weight_check '
in ' UPDATE task SET weight=-0.9838856091396 WHERE id = 16296 '
I'm sure that the source rpm of anaconda is OK,because I succed to
build
it in local mock environment. and
the repo is the same as the koji build server.
hope you do me a favor sincerely!
The system time on your hub must have been set back during an anaconda
build and there must be sufficiently few anaconda builds for this to
cause getAverageBuildDuration('anaconda') to return a negative number.
We should of course fix this, but you should also avoid rolling back the
time on your koji hosts, especially the hub and db hosts.
In the meantime, this patch should help
--- a/builder/kojid
+++ b/builder/kojid
@@ -2033,6 +2033,9 @@ class BuildArchTask(BaseTaskHandler):
avg = session.getAverageBuildDuration(name)
if not avg:
return
+if avg 0:
+self.logger.warn(Negative average build duration for %s:
%s, name, avg)
+return
# increase the task weight by 0.75 for every hour of build
duration
adj = (avg / 4800.0)
# cap the adjustment at +4.5
--
As Mike Bonnet said in message 2, one of anaconda builds had a
completion_time earlier than creation_time, so I find the one and remember
the build ID, then update the table build to make the completion_time
later than creation_time.
Now the problem was solved
Re: Promoting i386 version over x86_64?
On 11/18/09 07:55, Josephine Tannhäuser wrote: I think this is a script which reads your currently used architecture and provide a dl link. please insert a x86_64 livecd and try it again! Wrong. Going there with Fedora 11/x86_64 (firefox) offers the 32bit version too. cheers, Gerd -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt bugzilla reporting - does it work?
On Tue, 2009-11-17 at 11:33 +0100, Christoph Höger wrote: Hi, I just wanted to report an evolution crash report with abrt. All I get (besides a stacktrace) is libcurl failed HTTP Post. It would help if your bug report would be more informative: What version of abrt? Can you give the _complete_ error message? Since I suspect that libcurl generally can handle HTTP posts, I wonder if this is some general bug in abrt? There was a fix to name resolution, but since you did not give abrt version number, there is no way to know whether you run abrt with that fix or not. Did anybody submit bugs successfully using this tool? Yes. -- vda -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: More broken deps for F11 texlive-2009
On Tuesday 17 November 2009 08:54:38 Jindrich Novy wrote: Do you see anything broken on non-x86_64 arches? I checked the F12 repo and everything looks sane to me. You are right, it was a problem on my side. Jindrich -- José Abílio -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt bugzilla reporting - does it work?
On Wed, 18 Nov 2009 10:29:10 +0100, Denys wrote: Did anybody submit bugs successfully using this tool? Yes. Well, with F-12 and a segfault in Claws Mail, it created a bugzilla ticket for me, but I couldn't get it to upload/attach the backtrace. Not even when retrying multiple times to send the report again with the mark in the checkbox next to the backtrace info. No error message. With F-11, documentation on setting up abrt is either missing or placed somewhere where it's difficult to find. Simply installing the packages, the plugins/addons, the gui and starting the daemon doesn't yield anything [and I haven't search for external doc files yet]. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
2009/11/18 Gerd Hoffmann kra...@redhat.com On 11/18/09 07:55, Josephine Tannhäuser wrote: I think this is a script which reads your currently used architecture and provide a dl link. please insert a x86_64 livecd and try it again! Wrong. Going there with Fedora 11/x86_64 (firefox) offers the 32bit version too. cheers, Gerd There's no javascript on the page checking client arch; i think the idea was discarded, because the machines used to download and install most of the times are not the same. I really like the more download options link found in the spins website (which is awesome, kudos to the designers), showing an additional x86_64 download block with dhtml. cheers -- Guido Grazioli guido.grazi...@gmail.com Via Parri 11 48011 - Alfonsine (RA) Mobile: +39 347 1017202 (10-18) Key FP = 7040 F398 0DED A737 7337 DAE1 12DC A698 5E81 2278 Linked in: http://www.linkedin.com/in/guidograzioli -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review request...
On Wed, 18 Nov 2009 00:38:31 +0100, Martin wrote: https://bugzilla.redhat.com/show_bug.cgi?id=537587 Hm... on a very quick first look, you obviously don't follow https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Release The difference being that *you* point out a specific item in the guidelines (helpful!) whereas the reviewer pointed at the top-level Wiki page for maintainers only. What the heck? Comment 10 in that ticket is either a bad joke or poor attitude, IMO. If everybody were aware of all guidelines, remembered them all the time and never made mistakes, we would not need the review process and not the sponsorship process either. With regard to the sub-packages and the dozens of conditionals, at least making use of %bcond_with based conditional builds would be worthwhile. See e.g. /usr/lib/rpm/macros for bcond documentation. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: abrt / kernel oops issue
On 11/12/2009 06:50 PM, Dan Williams wrote: On Thu, 2009-11-12 at 10:31 -0700, Nathanael D. Noblet wrote: Hello, I've been running F12/rawhide from a preupgrade from F11 for a couple weeks now. I've just recently noticed the abrt feature. I started submitting the bugs it found in the kerneloops. Which has me wondering couple things. #1 - I have many many kerneloops, each stacktrace/log snippet seems fairly identical. I assume you would prefer not to get 20 identical abrt submitted bugs? Or should I submit them all? #2 - When looking at the trace it has the following line(s): Nov 10 09:15:57 iridium kernel: WARNING: at lib/list_debug.c:30 __list_add+0x68/0x81() (Tainted: GW ) ... Nov 10 09:15:57 iridium kernel: Pid: 2197, comm: Xorg Tainted: G W 2.6.31.5-127.fc12.x86_64 #1 I'm wondering why it is saying it is tainted.. or maybe Tainted: G mean Good?? I don't have any closed source modules loaded as far as I know. Unless Virtualbox is closed source but I didn't think it was. Virtualbox isn't running when this happens, though the module seems to be loaded. If you have an oops or BUG of any sort, I think that sets the taint flag for further oops reports, because after the first one you can't really trust that the stacktrace or internal kernel structures aren't corrupted. Most of the time they aren't, but you simply can't trust that. So I'd expect the first one to be untainted, and then subsequent oops reports to have the taint flag set. Of course if you start loading random kernel modules that didn't come with the kernel itself, you can also taint the kernel. If you have staging drivers loaded, you'll have the taint_crap flag set because staging drivers are crap. Dan #3 Validity of the bugs it is finding... It calls the following a kerneloops... Nov 11 16:56:41 iridium gnome-session[2259]: WARNING: Could not parse desktop file /etc/xdg/autostart/network-manager-netbook.desktop: Key file does not have key 'Name' Nov 11 16:56:41 iridium gnome-session[2259]: WARNING: could not read /etc/xdg/autostart/network-manager-netbook.desktop Nov 11 16:56:42 iridium kernel: executing set pll Nov 11 16:56:42 iridium kernel: executing set crtc timing Nov 11 16:56:42 iridium kernel: [drm] TMDS-15: set mode 25 Nov 11 16:56:42 iridium kernel: executing set pll Nov 11 16:56:42 iridium kernel: executing set crtc timing Nov 11 16:56:42 iridium kernel: [drm] TMDS-11: set mode 2f Nov 11 16:56:42 iridium kernel: fuse init (API version 7.12) Nov 11 16:56:43 iridium pulseaudio[2406]: pid.c: Daemon already running. Nov 11 16:56:46 iridium restorecond: Unable to watch (/home//public_html/*) No such file or directory do I submit this anyway? Thanks, just rying to do my part without burying you guys in senseless bug reports. ABRT's kerneloops plugin had some problems with false alarms, this should be fixed in the next release (this week). Jirka attachment: jmoskovc.vcf-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Tue, Nov 17, 2009 at 03:56:16PM -0500, Chris Ball wrote: Hi, I'm not sure how much of this can/should be automated. Sorry, not quite following -- what is the caution around automatically creating a new snapshot before each yum transaction? Why shouldn't it be automated? AIUI it will waste space. Snapshots are quick and easy to perform, but if you keep them around they can't be garbage collected. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Head-up - new firefox in rawhide
Hi, a new firefox (3.6 beta 2) just hit rawhide (a.k.a f13). There are some changes which affect everyone who builds with xulrunner-devel-unstable package. Mozilla decided to merge all include directories to one (mozbz#398573) and stop shipping stable/unstable packages. So all headers/libraries are merged to one big xulrunner-devel package (with respective pkgconfig files) and xulrunner-devel-unstable has been removed. What does it mean for you? 1) Change xulrunner-devel-unstable to xulrunner-devel in spec. file BuildRequires. 2) Switch libxul-embedding-unstable.pc to libxul-embedding.pc or libxul-unstable.pc to libxul.pc in make/configure scripts. 3) Rebuild the package and report any problem to BZ. ma. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091118 changes
Compose started at Wed Nov 18 08:15:06 UTC 2009 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A silly question about our FC tag
2009/11/18 Orcan Ogetbil oget.fed...@gmail.com: On Tue, Nov 17, 2009 at 10:18 AM, Jesse Keating wrote: On Mon, 2009-11-16 at 17:11 -0600, Jason L Tibbitts III wrote: Actually not if done in conjunction with a release bump, such as we do with a mass rebuild. Only if we make a promise to never use the same base n-v-r across the releases until whichever release we did the mass rebuild on is retired. You are correct in that if we did a mass rebuild in dist-f13, we could move to .f##, but consider 3 days later a maintainer wants to push a new upstream release across the branches: foo-1.2-1.fc11 foo-1.2-1.fc12 foo-1.2-1.f13 We're back in the same boat where the fc packages will be n-v-r higher. Is RPM so hard to hack to work this around? Orcan One may opt not to use the dist tag, of course. -- Mat Booth -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review request...
may be, but sponsors or reviewers doesn't have entire day free time. I have only asked reporter to post spec file + src.rpm file. The difference being that *you* point out a specific item in the guidelines (helpful!) whereas the reviewer pointed at the top-level Wiki page for maintainers only. What the heck? Comment 10 in that ticket is either a bad joke or poor attitude, IMO. If everybody were aware of all guidelines, remembered them all the time and never made mistakes, we would not need the review process and not the sponsorship process either. With regard to the sub-packages and the dozens of conditionals, at least making use of %bcond_with based conditional builds would be worthwhile. See e.g. /usr/lib/rpm/macros for bcond documentation. -- Itamar Reis Peixoto e-mail/msn/google talk/sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
On Tue, 2009-11-17 at 23:34 -0500, Chris Ball wrote: Given the above, do you think you'd be okay with having: Filesystem snapshot that will be active on next boot: drop-down Shouldn't it say next time volume is mounted instead of next boot? We can always special case rootfs to say next boot of course (since rootfs can't be unmounted until next boot). Also, what is the mechanism to configure this? Just a simple command from btrfs-progs (best)? Or does it require surgery to /etc/fstab and/or the initramfs (bad)? Create new whole-filesystem snapshot now: label apply in a Btrfs-specific section in Palimpsest? That's all that's needed for the UI component of this feature. From a 50,000 feet view all this sounds good to me. (Oh, and if it turns out that creating/destroying btrfs snaphots isn't a privileged operation (I can't remember at this point) it would probably make sense for Nautilus to just use the btrfs tools directly instead of going through a system daemon. There's just no need to overcomplicate things.) Creating a new snapshot is unprivileged, but mounting an old one (which nautilus would need to do in order to show you the contents of a previous snapshot, so that you can decide which files you want to restore from it) requires a mount(8) call for each snapshot. OK. We need to decide how all this is going to work - maybe some of it will go into GIO and be part of an abstraction that also works for other filesystems, maybe it will be a Nautilus-only feature. I don't know yet, leaning towards the latter right now, but I guess we'll find out. Thanks, David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Question about tagging
I'm trying to build cairomm 1.8.4 in devel, but the tags that I get are dist-f12, and when I try and actually do the build I get an error saying: /usr/bin/koji build dist-f12 'cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/cairomm/devel#cairomm-1_8_4-1_fc12' Usage: koji build [options] target URL (Specify the --help global option for a list of other help options) koji: error: Destination tag dist-f12 is locked make: *** [koji] Error 1 Shouldn't I be getting f13 tags with make tag? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about tagging
On 11/18/2009 10:29 AM, Rick L. Vinyard, Jr. wrote: Shouldn't I be getting f13 tags with make tag? If you run: cvs update -d in the top level checkout directory, you will. ;) ~spot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review request...
On Wed, 18 Nov 2009 12:44:50 -0200, Itamar wrote: may be, but sponsors or reviewers doesn't have entire day free time. True, but an entire day is not needed. And nobody forces you to become a reviewer [or a sponsor] and spend any time at all on reviewing or guiding [new] packagers. The community of Fedora Packagers can only work fine if everybody stays polite and calm even during disagreement [or misunderstandings and foreign language barriers]. I have only asked reporter to post spec file + src.rpm file. Many packagers don't know that maintaining a proper spec %changelog for relevant spec file changes and %release bumps are considered important during review already. Others add meaningless/dummy %changelog entries even in Fedora cvs. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Review request...
On Wed, Nov 18, 2009 at 1:43 PM, Michael Schwendt mschwe...@gmail.com wrote: On Wed, 18 Nov 2009 12:44:50 -0200, Itamar wrote: may be, but sponsors or reviewers doesn't have entire day free time. True, but an entire day is not needed. And nobody forces you to become a reviewer [or a sponsor] and spend any time at all on reviewing or guiding [new] packagers. The community of Fedora Packagers can only work fine if everybody stays polite and calm even during disagreement [or misunderstandings and foreign language barriers]. I have only asked reporter to post spec file + src.rpm file. Many packagers don't know that maintaining a proper spec %changelog for relevant spec file changes and %release bumps are considered important during review already. Others add meaningless/dummy %changelog entries even in Fedora cvs. I agree, for me it's very important to post updated spec file + src.rpm with or without changelog bumped Itamar Reis Peixoto e-mail/msn/google talk/sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFC: Btrfs snapshots feature for F13
Hi David, Shouldn't it say next time volume is mounted instead of next boot? We can always special case rootfs to say next boot of course (since rootfs can't be unmounted until next boot). Good point. That's fine. Also, what is the mechanism to configure this? Just a simple command from btrfs-progs (best)? Or does it require surgery to /etc/fstab and/or the initramfs (bad)? Josef's been thinking about exactly that -- the current situation requires you to add subvol=snapshot-name to the mount args, which indeed would require you to change fstab (for non-rootfs) or to add a rootflags= argument to the grub menu (for rootfs). He's considering changing the btrfs disk format to add a default subvolume for this fs field that would lead us to a simple btrfsctl command for setting that field instead. I agree that his solution's what we'd like. OK. We need to decide how all this is going to work - maybe some of it will go into GIO and be part of an abstraction that also works for other filesystems, maybe it will be a Nautilus-only feature. I don't know yet, leaning towards the latter right now, but I guess we'll find out. Makes sense. Thanks again. I've updated the feature draft to include the Palimpsest UI suggestion. - Chris. -- Chris Ball c...@laptop.org One Laptop Per Child -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: A silly question about our FC tag
Toshio Kuratomi a.bad...@gmail.com writes: On Wed, Nov 18, 2009 at 12:08:15AM -0500, Orcan Ogetbil wrote: Is RPM so hard to hack to work this around? There's many things that need to be changed in rpm but IMHO this isn't one of them. RPM produces predictable versioning. Hacking it up with special cases will lead nowhere but pain. Perhaps more to the point: changing this isn't worth spending *ANY* time on, let alone large amounts of time. fc is fine. regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about tagging
Michael Schwendt wrote: On Wed, 18 Nov 2009 08:53:16 -0700, Jr. wrote: Tom \spot\ Callaway wrote: On 11/18/2009 10:29 AM, Rick L. Vinyard, Jr. wrote: Shouldn't I be getting f13 tags with make tag? If you run: cvs update -d in the top level checkout directory, you will. ;) I did. What I generally run is 'cvs -PAd' I even removed the devel directory and re-checked it out by running 'cvs -PAd' in the top level directory. What about the common directory? That's the important one, one level above devel. $ cat cairomm/common/branches|grep devel devel:dist-f13:.fc13:fedora:13 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list That was it. Thanks. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
On Wed, Nov 18, 2009 at 1:55 AM, Josephine Tannhäuser josephine.tannhau...@googlemail.com wrote: 2009/11/18, Gregory Maxwell gmaxw...@gmail.com: I noticed that http://fedoraproject.org/get-fedora appears to be strongly promoting i386 Fedora over x86_64. Is this intentional or an oversight? I think this is a script which reads your currently used architecture and provide a dl link. please insert a x86_64 livecd and try it again! As others have pointed out: this is not so and probably can't produce reasonable results. On Wed, Nov 18, 2009 at 1:55 AM, Jeff Garzik jgar...@pobox.com wrote: However, if you just want a single download now button, 32-bit would get you the widest hardware coverage. Absolutely. Although it was my understanding that the stated goal was to encourage everyone on capable hardware to run x86_64, and previous editions of the download page did seem to do that. I don't personally have much of a horse in that race beyond the fact that I argued against dropping support for some older systems in the 32 bit build based on the position that users on new hardware should be running x86_64. There is obviously a trade-off in having the simplest possible install vs getting people the best platform support. Considering the complexity of the overall install I think the extra work to select an architecture at download time would be a comparatively small hurdle. In any case— the trade-off here should be consciously chosen and not the result of an oversight in the development of the download page. (Which I think think is generally quite good). -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Local users get to play root?
Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xorg and multitouch
On 11/17/09 9:14 PM, Chris Ball wrote: Hi, Multitouch means, several mousepointers and you can move them all seperately. No, that's what multi-pointer means. Multi-Pointer X is already in F12. ... Multitouch refers to technologies that involve extrapolating from motion of finger-shaped blobs on your input device to the idea that a user has performed some continuous motion with said finger(s), and reacting appropriately. It's not the same as multi-pointer X, but it does use the same core technology. Isn't two-finger-drag for scrolling and two-finger-taps for right-click a form of multitouch? Or are we talking about extending that to pinch, rotate, etc? -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 10:38 PM, nodata wrote: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! The subject of the mail doesn't actually match the description in the bug report. Richard Hughes says: PackageKit allows you to install signed content from signed repositories without a password by default. It only asks you to authenticate if anything is unsigned or the signatures are wrong If you have a problem with this, do explain why. Not suggesting it is not a problem but being more descriptive does help. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xorg and multitouch
On 11/18/2009 07:04 AM, Ikem Krueger wrote: The X level support is already in F12 - see: http://fedoraproject.org/wiki/Features/XI2 Application level support will come later Do you know when? I ask, because Windows and Mac OS already have them and Linux is a bit behind with it. Nevertheless I believe that our implementation will be better. ^^ Xorg has a lot of catching up to do. Just be patient. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Rahul Sundaram sunda...@fedoraproject.org: If you have a problem with this, do explain why. Not suggesting it is not a problem but being more descriptive does help. Well, the security is dependent on the strength of the repository/package signature verification scheme. I am not sure how that is done exactly. Perhaps someone could shed some light. -- Regards, Debayan Banerjee -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
No fuse module in Koji builds?
A package I'm building has an (optional) test which does a local non-root fuse mount in order to run some tests. In Koji this gives the error: fuse: device not found, try 'modprobe fuse' first So I have a couple of questions about this: I think in RHEL 5.4 the fuse module was added to the kernel -- are the Koji builders now based on the RHEL 5.4 kernel? If they are or will be, will local non-root fuse mounts be permitted during builds? As far as I'm aware there are no security issues with doing this, although possibly there may be unexpected interactions with Koji/mock if a build doesn't properly umount fuse mountpoints. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Rahul Sundaram sunda...@fedoraproject.org: On 11/18/2009 10:38 PM, nodata wrote: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! The subject of the mail doesn't actually match the description in the bug report. Richard Hughes says: PackageKit allows you to install signed content from signed repositories without a password by default. It only asks you to authenticate if anything is unsigned or the signatures are wrong If you have a problem with this, do explain why. Not suggesting it is not a problem but being more descriptive does help. Well, it's all a bit inconsistent presently: $ yum install maxima Loaded plugins: presto, refresh-packagekit You need to be root to perform this command. $ maxima Command not found. Install package 'maxima' to provide command 'maxima'? [N/y] * Installing packages.. * Getting information.. * Resolving dependencies.. The following packages have to be installed: sbcl-1.0.30-2.fc12.x86_64 Steel Bank Common Lisp wxBase-2.8.10-6.fc12.x86_64Non-GUI support classes from the wxWidgets library wxGTK-2.8.10-6.fc12.x86_64 GTK2 port of the wxWidgets GUI library gnuplot-common-4.2.6-1.fc12.x86_64 common gnuplot parts cl-asdf-20071110-7.fc12.noarch Another System Definition Facility gnuplot-4.2.6-1.fc12.x86_64A program for plotting mathematical expressions and data maxima-runtime-sbcl-5.19.2-1.fc12.x86_64 Maxima compiled with SBCL common-lisp-controller-6.15-8.fc12.noarch Common Lisp source and compiler manager Proceed with changes? [N/y] * Waiting for authentication.. * Running.. * Resolving dependencies.. * Downloading packages.. * Testing changes.. * Installing packages.. * Scanning applications.. [...@withnail ~]$ Command not found. Install package 'maxima' to provide command 'maxima'? [N/y] ^C ... and what's more it bails with command not found anyway which component isn't working here? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
rawhide report: 20091118 changes
Compose started at Wed Nov 18 08:15:06 UTC 2009 New package bucardo Postgres replication system for both multi-master and multi-slave operations New package gwsmhg A PyGTK GUI wrapper for hg and mq New package picocontainer Dependency-injection container New package picturetile Tiles a bunch of images into one large photo wall Updated Packages: atanks-4.1-3.fc13 - * Fri Nov 06 2009 Jon Ciesla l...@jcomserv.net - 4.1-3 - Fix crash on SMP systems. bash-completion-1.1-3.fc13 -- * Tue Nov 17 2009 Ville Skyttä ville.sky...@iki.fi - 1:1.1-3 - Prepare for smooth coexistence with yum upstream completion. * Sun Nov 08 2009 Ville Skyttä ville.sky...@iki.fi - 1:1.1-2 - Use yum-utils completion instead of ours if available. bouml-4.16.2-1.fc13 --- * Sat Nov 14 2009 Debarshi Ray ri...@fedoraproject.org - 4.16.2-1 - Version bump to 4.16.2. (Red Hat Bugzilla #525932) * Previous releases can not read a project saved with this version, but projects made by previous releases can be read. * Allows to import a project as a library. A project imported as a library can't be modified in the importing project, but it can be updated to follow changes done in the imported project. * It is now possible to show/hide the visibility of the relations between classes depending on the value of the drawing settings show relation visibility. By default the visibility of the relations of not shown. * Messages in a sequence diagram can now be stereotyped (by textual stereotype out of profile). Default message stereotypes can be set through the default stereotype dialog. * It is now possible to ask for to draw a decomposition indicator icon in a state in a state diagram. By default the icon is not shown. * The parent of a state, pseudo state and region can be changed through drag drop in the browser while staying inside the container state machine. * In activity diagrams the stereotype of an action is now written, except for opaque actions when you ask for to show their definition through the drawing settings. * Except for a few exceptions, when resizing elements like classes the edge didn't follow the cursor. Fixed. * It was difficult to select a line drawn between an element to an other element placed inside the first one (for instance between a state machine and a sub state drawn inside its state machine). Fixed. * Plug-out: + Manage stereotype on messages in a sequence diagram. * Project Control: + Manage projects imported as a library. * XMI2 Generator: + Export stereotype of messages through an extension. * Translation updates: fr and de. * http://bouml.free.fr/historic.html chess-1.0-28.fc13 - * Tue Nov 17 2009 Bruno Wolff III br...@wolff.to - 1.2-28 - Avoid Vector3 conflict with ogre and ois 1.2 cpqarrayd-2.3-13.fc13 - * Tue Nov 17 2009 David Juran dju...@redhat.com - 2.3-13 - rebuild for new libnetsnmp dracut-002-24.git44a6a0d9.fc13 -- * Tue Nov 17 2009 Harald Hoyer har...@redhat.com 002-23 - install xdr utils for multipath (bug #463458) * Tue Nov 17 2009 Harald Hoyer har...@redhat.com 002-24 - put fips module in a subpackage (bug #537619) dracut-modules-olpc-0.2.7-1.fc13 * Tue Nov 17 2009 Daniel Drake d...@laptop.org - 0.2.7-1 - New version eclipse-3.5.1-21.fc13 - * Tue Nov 17 2009 Alexander Kurtakov akurt...@redhat.com 1:3.5.1-20 - Fix ppc64 swt jar version. * Tue Nov 17 2009 Andrew Overholt overh...@redhat.com 1:3.5.1-21 - Fix typo in memory settings. eclipse-pydev-1.5.1-1.fc13 -- * Wed Nov 18 2009 Alexander Kurtakov akurt...@redhat.com 1:1.5.1-1 - Update to 1.5.1. evolution-2.29.2-1.fc13 --- * Tue Nov 17 2009 Matthew Barnes mbar...@redhat.com - 2.29.2-1.fc13 - Update to 2.29.2 - Synchronize spec file with my kill-bonobo test package. * Tue Oct 27 2009 Matthew Barnes mbar...@redhat.com - 2.29.1-1.fc13 - Update to 2.29.1 - Bump evo_major to 2.30. - Drop Bonobo + ORBit dependency (yay!). - Remove option to use OpenSSL instead of NSS. - Uninstall GConf schemas during %pre and %preun. frinika-0.6.0-1.fc13 * Tue Nov 17 2009 Orcan Ogetbil oget [DOT] fedora [AT] gmail [DOT] com - 0.6.0-1 - Update to 0.6.0. gdal-1.6.2-1.fc13 - * Tue Nov 17 2009 Orion Poplawski or...@cora.nwra.com - 1.6.2-1 - Update to 1.6.2 - Rebuild for netcdf 4.1.0 generic-release-12-1 * Mon Nov 16 2009 Tom spot Callaway tcall...@redhat.com - 12-1 - Update for F12 final gimp-2.6.7-3.fc13 - * Tue Nov 17 2009 Nils Philippsen n...@redhat.com - 2:2.6.7-3 - avoid overflow in the BMP image file plugin (#537356) - avoid overflow in the PSD image file plugin (#537370) - update jpeg-units patch git-cola-1.4.0.5-1.fc13
Re: Local users get to play root?
On Wed, 2009-11-18 at 18:08 +0100, nodata wrote: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! Seems fair as the default for a desktop installation. Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin. [1]: https://fedoraproject.org/wiki/Features/UserAccountDialog -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 18:08, schrieb nodata: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! Just to elaborate: A local user is allowed to install software on the machine without being prompted for the root password. This is a recipe for disaster in my opinion. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
nodata wrote: Am 2009-11-18 18:08, schrieb nodata: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! Just to elaborate: A local user is allowed to install software on the machine without being prompted for the root password. This is a recipe for disaster in my opinion. So much for granting shell access on my servers. . . -- in your fear, seek only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 18:14, schrieb Rahul Sundaram: On 11/18/2009 10:38 PM, nodata wrote: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! The subject of the mail doesn't actually match the description in the bug report. Richard Hughes says: PackageKit allows you to install signed content from signed repositories without a password by default. It only asks you to authenticate if anything is unsigned or the signatures are wrong If you have a problem with this, do explain why. Not suggesting it is not a problem but being more descriptive does help. Rahul Thanks. I have changed the title to: All users get to install software on a machine they do not have the root password to -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Jon Ciesla wrote: nodata wrote: Am 2009-11-18 18:08, schrieb nodata: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! Just to elaborate: A local user is allowed to install software on the machine without being prompted for the root password. This is a recipe for disaster in my opinion. So much for granting shell access on my servers. . . You have PackageKit installed on servers? really? -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 18:45, schrieb Bastien Nocera: On Wed, 2009-11-18 at 18:08 +0100, nodata wrote: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! Seems fair as the default for a desktop installation. It's the opposite behaviour to what is the known behaviour of Linux. The default should be for the superuser to manage the box, with an option for him or her to allow all users to install software on the box. Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin. [1]: https://fedoraproject.org/wiki/Features/UserAccountDialog -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 11:19 PM, nodata wrote: Thanks. I have changed the title to: All users get to install software on a machine they do not have the root password to .. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 18:48, schrieb Rahul Sundaram: On 11/18/2009 11:19 PM, nodata wrote: Thanks. I have changed the title to: All users get to install software on a machine they do not have the root password to .. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail. Rahul Why is it a problem? For all of the reasons that it has never been a problem before. For the reason that the user is not the administrator or the box, for the reason that the user is the user for a reason, for the reason that by default Linux should act like Linux, for the reason that the default is bad, for the reason that this is undocumented, for the reason that it assumes automatic updates are enabled, for the reason that the user is not the one with knowledge of the box and what resources are available on it, for the reason that it may be against corporate policy, for the reason of change management... -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Seth Vidal wrote: On Wed, 18 Nov 2009, Jon Ciesla wrote: nodata wrote: Am 2009-11-18 18:08, schrieb nodata: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! Just to elaborate: A local user is allowed to install software on the machine without being prompted for the root password. This is a recipe for disaster in my opinion. So much for granting shell access on my servers. . . You have PackageKit installed on servers? really? -sv I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it. -- in your fear, seek only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 06:49 PM, Seth Vidal wrote: On Wed, 18 Nov 2009, Jon Ciesla wrote: nodata wrote: Am 2009-11-18 18:08, schrieb nodata: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! Just to elaborate: A local user is allowed to install software on the machine without being prompted for the root password. This is a recipe for disaster in my opinion. So much for granting shell access on my servers. . . You have PackageKit installed on servers? really? Why shouldn't he? AFAIK there is nothing in the package warning users not to install this on a server. What is the appropriate way to audit this kind of stuff? Presuming that PackageKit uses PolicyKit to aquire the necessary privileges is there a way to query PolicyKit and ask show me all instances where a process can acquire root privileges without being asked for a password? I don't think it's a good idea to rely on admins knowing the magic handshake (or in this case the magic package list of dangerous apps) for security. Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 11:27 PM, nodata wrote: Why is it a problem? For all of the reasons that it has never been a problem before. For the reason that the user is not the administrator or the box, for the reason that the user is the user for a reason, for the reason that by default Linux should act like Linux, for the reason that the default is bad, All of these seems rather circular. for the reason that this is undocumented, I have asked for more documentation already which I consider a valid point. for the reason that it assumes automatic updates are enabled, I am not sure why you say that? Automatic updates are not enabled by default. for the reason that the user is not the one with knowledge of the box and what resources are available on it, for the reason that it may be against corporate policy, for the reason of change management... Should the defaults be targeted towards home users or corporate desktop considering the short lifecycle of Fedora and the target audience? I am not sure there are corporate deployments but wouldn't they be heavily customized their desktop deployments and kickstarting it anyway? Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Jon Ciesla wrote: Seth Vidal wrote: On Wed, 18 Nov 2009, Jon Ciesla wrote: nodata wrote: Am 2009-11-18 18:08, schrieb nodata: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! Just to elaborate: A local user is allowed to install software on the machine without being prompted for the root password. This is a recipe for disaster in my opinion. So much for granting shell access on my servers. . . You have PackageKit installed on servers? really? -sv I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it. Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server. If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Dennis J. wrote: You have PackageKit installed on servers? really? Why shouldn't he? AFAIK there is nothing in the package warning users not to install this on a server. like I said in another email - I think of installing things on servers as 'barest minimal' and then adding things I require. Nothing else. Maybe I'm in the minority. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 19:04, schrieb Seth Vidal: On Wed, 18 Nov 2009, Jon Ciesla wrote: Seth Vidal wrote: On Wed, 18 Nov 2009, Jon Ciesla wrote: nodata wrote: Am 2009-11-18 18:08, schrieb nodata: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! Just to elaborate: A local user is allowed to install software on the machine without being prompted for the root password. This is a recipe for disaster in my opinion. So much for granting shell access on my servers. . . You have PackageKit installed on servers? really? -sv I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it. Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server. If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have. -sv Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Seth Vidal wrote: On Wed, 18 Nov 2009, Jon Ciesla wrote: Seth Vidal wrote: On Wed, 18 Nov 2009, Jon Ciesla wrote: nodata wrote: Am 2009-11-18 18:08, schrieb nodata: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! Just to elaborate: A local user is allowed to install software on the machine without being prompted for the root password. This is a recipe for disaster in my opinion. So much for granting shell access on my servers. . . You have PackageKit installed on servers? really? -sv I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it. Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server. If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have. -sv That's generally my MO as well. Sometime, however, as I have mostly legacy hardware, some machines need to perform multiple functions. Really, though sometimes it's nice to tunnel a GUI through SSH, if I want to browse the repo that way. Usually yum search, etc is enough. Sometimes it's not, quite. -- in your fear, seek only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xorg and multitouch
Xorg has a lot of catching up to do. Just be patient. I am not very good at it. xD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, nodata wrote: -sv I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it. Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server. If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have. -sv Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what. right - which is why I wouldn't install PK on a server. yum doesn't allow users to install pkgs, only root. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xorg and multitouch
On 11/18/2009 11:38 PM, Ikem Krueger wrote: Xorg has a lot of catching up to do. Just be patient. I am not very good at it. xD Alternatively, make yourself busy by contributing :-) Help us. http://join.fedoraproject.org Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Promoting i386 version over x86_64?
I noticed that http://fedoraproject.org/get-fedora appears to be strongly promoting i386 Fedora over x86_64. Is this intentional or an oversight? I agree, that was my first impression as well. However, if you just want a single download now button, 32-bit would get you the widest hardware coverage. And you can run a 32-bit OS on an 64-bit architecture. The other way doesn't work. ^^ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 23:18:28 +0530, Rahul Sundaram sunda...@fedoraproject.org wrote: On 11/18/2009 11:19 PM, nodata wrote: Thanks. I have changed the title to: All users get to install software on a machine they do not have the root password to .. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail. Besides other issues listed, the packages being installed may be privileged programs that the admin doesn't want on the system, may start services or schedule runs at specified times by default which might considered a problem by the admin, the extra packages may use up too much disk space and cause problems. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Seth Vidal wrote: On Wed, 18 Nov 2009, nodata wrote: -sv I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it. Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server. If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have. -sv Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what. right - which is why I wouldn't install PK on a server. yum doesn't allow users to install pkgs, only root. -sv I just found PackageKit on a server that's never been anything but. It was installed fith FC-2, which IIRC is pre-PackageKit. Does this mean it was pulled in by something else that no longer requires it? -- in your fear, seek only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 17:45:26 +, Bastien Nocera bnoc...@redhat.com wrote: Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin. This seems pretty reasonable. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 17:45 +, Bastien Nocera wrote: On Wed, 2009-11-18 at 18:08 +0100, nodata wrote: Yikes! When was it decided that non-root users get to play root? Ref: https://bugzilla.redhat.com/show_bug.cgi?id=534047 This is horrible! Seems fair as the default for a desktop installation. Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin. [1]: https://fedoraproject.org/wiki/Features/UserAccountDialog And what's wrong with the previous behavior where you were explicitly requested (through a checkbox) whether you liked to give this privilege to users or not ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Hi, On Wed, Nov 18, 2009 at 12:08 PM, nodata l...@nodata.co.uk wrote: Yikes! When was it decided that non-root users get to play root? This is hardly the first uid 0 operation we've granted users access to in the operating system, and it won't be the last. For example, on a timesharing Unix system, non-uid 0 can't reboot the machine, but it's clearly silly to ask for a root password to reboot for the unmanaged case, so years ago the consolehelper system was added, and that privilege is currently given to users at a physical display for the machine. We've used the console concept as our only tool in this respect for a long time, and PolicyKit will ultimately replace all of it with a far more fine grained system. So you raise a reasonable issue, which is how do you know when the defaults change, or new privileges are added? We don't have a very good system for that now; ideally we would detect when new packages are added to @gnome-desktop that include PolicyKit policies, and use that as a basis for release notes type of thing. But, bottom line, if you're administering a Fedora-derived desktop, you will need to get familiar with PolicyKit, and you may need to tweak the defaults, which are more targeted for the self-managed case. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Jon Ciesla wrote: Seth Vidal wrote: On Wed, 18 Nov 2009, nodata wrote: -sv I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it. Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server. If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have. -sv Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what. right - which is why I wouldn't install PK on a server. yum doesn't allow users to install pkgs, only root. -sv I just found PackageKit on a server that's never been anything but. It was installed fith FC-2, which IIRC is pre-PackageKit. Does this mean it was pulled in by something else that no longer requires it? Did you 'yum update' the box from fc-2 to whatever it is now? or how did you get there? -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 11:44 PM, Bruno Wolff III wrote: Besides other issues listed, the packages being installed may be privileged programs that the admin doesn't want on the system, may start services or schedule runs at specified times by default which might considered a problem by the admin, the extra packages may use up too much disk space and cause problems. This assumes the user is different from a admin, which is not true for a personal desktop. This revolves back to what the default target audience should be. PackageKit target audience is defined at http://www.packagekit.org/pk-profiles.html If it doesn't match what Fedora wants, then it should be tweaked but the larger question should be addressed first. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Konstantin Ryabitsev wrote: 2009/11/18 Jon Ciesla l...@jcomserv.net: A local user is allowed to install software on the machine without being prompted for the root password. This is a recipe for disaster in my opinion. So much for granting shell access on my servers. . . I may be wrong, but I understand that this behaviour of PackageKit only applies to users with direct console access (i.e. not remote shells). So, only users that are logged in via GDM or TTY would be able to perform such tasks. This significantly limits the number of users with powers to install signed software -- almost to the point of where it sounds like a fair trade-off. If someone has physical access to the machine, then heck -- it's not like they don't already effectively own it. Not saying it's a good default policy -- but let's cool our heads. might be worth testing that feature with pkcon from an ssh terminal. I've not done that yet but I think it would be worth checking out. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 11:48 PM, Colin Walters wrote: So you raise a reasonable issue, which is how do you know when the defaults change, or new privileges are added? We don't have a very good system for that now; ideally we would detect when new packages are added to @gnome-desktop that include PolicyKit policies, and use that as a basis for release notes type of thing. But, bottom line, if you're administering a Fedora-derived desktop, you will need to get familiar with PolicyKit, and you may need to tweak the defaults, which are more targeted for the self-managed case. Detailed documentation and release notes must have been done as part of this change however. Can that be provided now, so that we can update the release notes? Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 19:18, schrieb Colin Walters: Hi, On Wed, Nov 18, 2009 at 12:08 PM, nodatal...@nodata.co.uk wrote: Yikes! When was it decided that non-root users get to play root? This is hardly the first uid 0 operation we've granted users access to in the operating system, and it won't be the last. For example, on a timesharing Unix system, non-uid 0 can't reboot the machine, but it's clearly silly to ask for a root password to reboot for the unmanaged case, so years ago the consolehelper system was added, and that privilege is currently given to users at a physical display for the machine. We've used the console concept as our only tool in this respect for a long time, and PolicyKit will ultimately replace all of it with a far more fine grained system. So you raise a reasonable issue, which is how do you know when the defaults change, or new privileges are added? We don't have a very good system for that now; ideally we would detect when new packages are added to @gnome-desktop that include PolicyKit policies, and use that as a basis for release notes type of thing. But, bottom line, if you're administering a Fedora-derived desktop, you will need to get familiar with PolicyKit, and you may need to tweak the defaults, which are more targeted for the self-managed case. This is a major change. I vote for secure by default. If the admin wishes this surprise-root feature to be enabled he can enable it. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 13:05:31 -0500, Seth Vidal skvi...@fedoraproject.org wrote: like I said in another email - I think of installing things on servers as 'barest minimal' and then adding things I require. Nothing else. Maybe I'm in the minority. I don't like the idea of packages being installed meaning I want them to run services, schedule cron jobs or give elevated access by default. This kind of thing makes it easy to shoot yourself in the foot. The purpose of not installing packages should be to save disk space and resources needed for updates, not security and integrity. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Bruno Wolff III wrote: On Wed, Nov 18, 2009 at 23:18:28 +0530, Rahul Sundaram sunda...@fedoraproject.org wrote: On 11/18/2009 11:19 PM, nodata wrote: Thanks. I have changed the title to: All users get to install software on a machine they do not have the root password to .. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail. Besides other issues listed, the packages being installed may be privileged programs that the admin doesn't want on the system, may start services or schedule runs at specified times by default which might considered a problem by the admin, the extra packages may use up too much disk space and cause problems. If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 23:29 +0530, Rahul Sundaram wrote: Should the defaults be targeted towards home users or corporate desktop considering the short lifecycle of Fedora and the target audience? I am not sure there are corporate deployments but wouldn't they be heavily customized their desktop deployments and kickstarting it anyway? I am not a corporation yet *I* manage the machines I have at home, and if *I* give an account to my friend foo *I* don't want him to be able to install nothing without asking me first, not even by mistake. For better of worse even desktop Linux is a multi-user system and this default is just crap and totally unnecessary given the previous version allowed you to allow a user forever explicitly and without hassles. This way I have to *fsck* remember each time to change it, this is *wrong*, it doesn't respect the basic philosophy of least surprise. I would almost consider it a security vulnerability and ask for a CVE to be issued. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 23:18 +0530, Rahul Sundaram wrote: On 11/18/2009 11:19 PM, nodata wrote: Thanks. I have changed the title to: All users get to install software on a machine they do not have the root password to .. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail. That is important, and personally I have a lot of sympathy for some of the desired use cases¹ I've heard about. On the other hand this does open up a lot of ways to attack the system, esp. given that there is _no_ authentication ... as I had expected that code running as the user would still have to authenticate as the user (Hello Linux virus makers, welcome to the party). Off the top of my head, these are the first things I'd look at for attacking a system with PK and this config: 1. Does install of obsoleting packages come under the same auth. (if so I can now arbitrarily upgrade certain packages). 2. Does install of installonly come under the same auth. (if so I can now stop kernel upgrades). 3. Are there any attacks due to disk space used? Eg. If /var is low² I can probably install enough pkgs to make logging stop. 4. Are there any attacks against packages with default on services? (Note that you can almost certainly wait until there is an attack, and then install the insecure service). 5. Are there any attacks against packages with set*id apps? (Dito. with the waiting approach in #4). 6. Are there any attacks against packages which provide plugins? (Dito. waiting) 7. And the most obvious one ... how hard is it to get a bad package into one of the repos. that the machine has enabled. ¹ Things like letting a spouse/child install a new game/theme/editor/etc. without having to get their admin to do it. ² If /var is on a separate partition then spamming /var/tmp is a goood first step here. -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.25 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, nodata wrote: Am 2009-11-18 19:18, schrieb Colin Walters: This is a major change. I vote for secure by default. If the admin wishes this surprise-root feature to be enabled he can enable it. I'm not sure how this is 'surprise root'. IT will only allow installs of pkgs signed with a key you trust from a repo you've setup. which pretty much means: if the admin trusts the repo, then it is okay. if the admin doesn't trust the repo it should NOT be on the box and enabled b/c an untrusted repo can nuke your entire world. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 07:05 PM, Seth Vidal wrote: On Wed, 18 Nov 2009, Dennis J. wrote: You have PackageKit installed on servers? really? Why shouldn't he? AFAIK there is nothing in the package warning users not to install this on a server. like I said in another email - I think of installing things on servers as 'barest minimal' and then adding things I require. Nothing else. Maybe I'm in the minority. In fact I agree with you but this doesn't really address my point. How do you make sure the packages that are part of your minimal list don't introduce such a backdoor with the next update? I think the existence of PolicyKit actually could allow us to query it in the way i mentioned in my previous mail and get a quick picture of the privileges applications have access to. Consider it the PK equivalent of scanning your filesystems for setuid files. Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 13:10 -0500, Seth Vidal wrote: Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what. right - which is why I wouldn't install PK on a server. yum doesn't allow users to install pkgs, only root. Seth, the fact you prefer to use yum doesn't make it right to have an insecure-by-default policy. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 12:16 -0600, Bruno Wolff III wrote: On Wed, Nov 18, 2009 at 17:45:26 +, Bastien Nocera bnoc...@redhat.com wrote: Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin. This seems pretty reasonable. In the meanwhile the F-11 policy was just fine. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Seth Vidal skvi...@fedoraproject.org: I may be wrong, but I understand that this behaviour of PackageKit only applies to users with direct console access (i.e. not remote shells). So, only users that are logged in via GDM or TTY would be able to perform such tasks. This significantly limits the number of users with powers to install signed software -- almost to the point of where it sounds like a fair trade-off. If someone has physical access to the machine, then heck -- it's not like they don't already effectively own it. Not saying it's a good default policy -- but let's cool our heads. might be worth testing that feature with pkcon from an ssh terminal. I've not done that yet but I think it would be worth checking out. Looks to be the case: bu...@localhost's password: [bu...@smaug ~]$ uqm Command not found. Install package 'uqm' to provide command 'uqm'? [N/y] * Installing packages.. * Getting information.. * Resolving dependencies.. The following packages have to be installed: autodownloader-0.3.0-3.fc12.noarch GUI-tool to automate the download of certain files Proceed with changes? [N/y] * Waiting for authentication.. The transaction failed: not-authorized, Failed to obtain authentication. [bu...@smaug ~]$ Let's calm down now, please. :) -- McGill University IT Security Konstantin Ryabitsev Montréal, Québec -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Simo Sorce wrote: On Wed, 2009-11-18 at 13:10 -0500, Seth Vidal wrote: Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what. right - which is why I wouldn't install PK on a server. yum doesn't allow users to install pkgs, only root. Seth, the fact you prefer to use yum doesn't make it right to have an insecure-by-default policy. I didn't say it did - I said it didn't make sense to have items like PK on servers. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 13:22:03 -0500, Seth Vidal skvi...@fedoraproject.org wrote: If there are pkgs which run daemons which are defaulting to ON when installed or on next reboot - then we should be auditing those pkgs. Last I checked we default to OFF and that should continue to be the case. There definitely is some user oriented stuff that gets run by default, but maybe only when using a desktop. Bluetooth seems to work that way. Installing beagle and another indexing program I noticed recently but don't remember the name of, schedule indexing operations by default. There is a mail client that has an annoying desktop popup by the default just for having it installed. There are other things that are needed for lots of stuff to function, such as pulseaudio, so it's not always clear cut what the proper default should be. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 13:19 -0500, Konstantin Ryabitsev wrote: This significantly limits the number of users with powers to install signed software -- almost to the point of where it sounds like a fair trade-off. If someone has physical access to the machine, then heck -- it's not like they don't already effectively own it. Most of my users wouldn't be able to own it even if I let a root shell open, but they would definitely be able to install or remove packages using the GUI. The difference is huge. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Seth Vidal wrote: On Wed, 18 Nov 2009, Jon Ciesla wrote: Seth Vidal wrote: On Wed, 18 Nov 2009, nodata wrote: -sv I do if it's in the default DVD install, or was pulled in in an upgrade. I've never intentionally installed it, and yes I do. Never imagined it would be a problem. I'll remove it. Maybe you and I have a different concept of 'Servers'. But I tend to install @core only and then remove items whenever I can for a server. If it is a bad day I'll install X b/c something requires it but for servers I try to avoid anything beside the barest minimal I can have. -sv Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what. right - which is why I wouldn't install PK on a server. yum doesn't allow users to install pkgs, only root. -sv I just found PackageKit on a server that's never been anything but. It was installed fith FC-2, which IIRC is pre-PackageKit. Does this mean it was pulled in by something else that no longer requires it? Did you 'yum update' the box from fc-2 to whatever it is now? or how did you get there? -sv Yes, precisely, one release at a time. Plan to do 12 in a few days. -- in your fear, seek only peace in your fear, seek only love -d. bowie -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 13:05 -0500, Seth Vidal wrote: On Wed, 18 Nov 2009, Dennis J. wrote: You have PackageKit installed on servers? really? Why shouldn't he? AFAIK there is nothing in the package warning users not to install this on a server. like I said in another email - I think of installing things on servers as 'barest minimal' and then adding things I require. Nothing else. Maybe I'm in the minority. I think the phrase would be shrinking majority Picture Windows Server for a moment. Now picture that admin coming over to administer a new Linux server. What's he gonna install? Click Next repeatedly. Not to mention the number of gui administrative tools that are getting front billing or even becoming stated mandatory options for certain applications, and, yes, we can always X11Forward, vnc or some such to remotely administer with those tools, but it still means that the GUI is being installed on more servers and the folks developing these GUI tools had better be security conscious in choosing defaults I don't think this one was a *good* choice. --Rob -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Dennis J. wrote: In fact I agree with you but this doesn't really address my point. How do you make sure the packages that are part of your minimal list don't introduce such a backdoor with the next update? You check them. That's the best you can do. It's just like anything else: How are you sure no one introduces a package into 'updates' which obsoletes glibc? We check them and hope we catch problems. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 13:23 -0500, Seth Vidal wrote: I'm not sure how this is 'surprise root'. IT will only allow installs of pkgs signed with a key you trust from a repo you've setup. which pretty much means: if the admin trusts the repo, then it is okay. if the admin doesn't trust the repo it should NOT be on the box and enabled b/c an untrusted repo can nuke your entire world. I may trust the repo, that doesn't mean I want to allow installation of any package that happens to live on that repo. The problem is the *Default* not the fact that you can consciously allow users to update without a password. On some machines I allow that no problem cause I explained the users how to do things, on some others not, and most importantly I do that per user. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 19:28, schrieb Seth Vidal: On Wed, 18 Nov 2009, Simo Sorce wrote: On Wed, 2009-11-18 at 13:10 -0500, Seth Vidal wrote: Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what. right - which is why I wouldn't install PK on a server. yum doesn't allow users to install pkgs, only root. Seth, the fact you prefer to use yum doesn't make it right to have an insecure-by-default policy. I didn't say it did - I said it didn't make sense to have items like PK on servers. It doesn't make sense to define the security setup of a machine based on oh well packagekit is installed, so it must be a desktop machine for which there is one or maybe two primary users who are all trusted to decide if they want to install software. The fact is that there is quite a lot of badly written software that requires X to install. In fact, Red Hat's documentation tends to assume that X is installed by default. So do Red Hat's courses. And even their toolset. Ever used system-config-lvm-tui? No, it doesn't exist. If X is there, PackageKit is there. The claimed link between the intended use and security profile of a machine depending on whether PackageKit is installed makes no sense. It doesn't matter if I or you prefer @core on our servers, the customers want X because they're new to Linux and feel comfortable with it. They won't have some arcane knowledge about the disconnect between yum and rpm with packagekit, and how sometimes you have to be root, sometimes you don't. Secure by default please, otherwise turn off selinux by default. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 13:28 -0500, Seth Vidal wrote: On Wed, 18 Nov 2009, Simo Sorce wrote: On Wed, 2009-11-18 at 13:10 -0500, Seth Vidal wrote: Maybe you have a different concept of security, but I don't want any user on the server installing software, no matter what. right - which is why I wouldn't install PK on a server. yum doesn't allow users to install pkgs, only root. Seth, the fact you prefer to use yum doesn't make it right to have an insecure-by-default policy. I didn't say it did - I said it didn't make sense to have items like PK on servers. add for me and I can agree with you. Note I also don't like to install desktop grade packages on servers, but that's just a preference, and should in no way change the security of the machine. Conscious choices: +1 Insecure defaults: -1 Difficult to find out how to change insecure defaults: -10 Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Simo Sorce sso...@redhat.com: On Wed, 2009-11-18 at 13:19 -0500, Konstantin Ryabitsev wrote: This significantly limits the number of users with powers to install signed software -- almost to the point of where it sounds like a fair trade-off. If someone has physical access to the machine, then heck -- it's not like they don't already effectively own it. Most of my users wouldn't be able to own it even if I let a root shell open, but they would definitely be able to install or remove packages using the GUI. The difference is huge. If I have physical access to your machine, I'll own it. I may have to use tools to get to the HDD, but it's only a question of time and dedication. Now, there can be situations where someone has access to the TTY console or GDM (usually when it's a VM guest or a machine behind a network KVM), but most often, if someone can log in on the console, they are sitting in front of the physical box, to which they have full access. Regards, -- McGill University IT Security Konstantin Ryabitsev Montréal, Québec -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 19:16, schrieb Bruno Wolff III: On Wed, Nov 18, 2009 at 17:45:26 +, Bastien Nocerabnoc...@redhat.com wrote: Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin. This seems pretty reasonable. I don't like the way Fedora is going with this: digging out something that works and saying we'll replace it later makes no sense. Make it work now, or *keep it in*. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 13:41 -0500, Konstantin Ryabitsev wrote: 2009/11/18 Simo Sorce sso...@redhat.com: On Wed, 2009-11-18 at 13:19 -0500, Konstantin Ryabitsev wrote: This significantly limits the number of users with powers to install signed software -- almost to the point of where it sounds like a fair trade-off. If someone has physical access to the machine, then heck -- it's not like they don't already effectively own it. Most of my users wouldn't be able to own it even if I let a root shell open, but they would definitely be able to install or remove packages using the GUI. The difference is huge. If I have physical access to your machine, I'll own it. I may have to use tools to get to the HDD, but it's only a question of time and dedication. *you* are not one of my users, and this has nothing to do with *you* hacking in my machine. If I have physical access to a machine I do not even care about what's installed on it. In 99% of the cases I will just be able to boot from a live cd. That's a completely different issue. Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Once upon a time, Rahul Sundaram sunda...@fedoraproject.org said: .. if the packages are signed and from a signed repository. So, you left out the important part. Explain why this is a problem in a bit more detail. Fedora has made a big push into the multi-user desktop (which many home computers are now) with things like fast user switching. In many such setups, not all users are considered administrators of the system (think parents and kids for example). However, Fedora continues to slip in (with no announcement and no documentation on how to change) things that allow the console user to be an administrator without any additional authentication. The answer here has been well root should lock it down. With the ever-increasing complexity of the system, it is becoming more difficult than ever to find (or even know about) all of the ways a system musth be locked down. find / -perm +6000 doesn't cut it anymore, but there's no documentation of all the ways a regular user can do administrative tasks without an administrative password. It seems the latest way of doing this is via PolicyKit. IMHO all PolicyKit configuration should be secure by default, and then desktop spins can include overrides in /etc to loosen-up security where desired. This would also make it much easier to find and clearer to see what might should be changed for local policy. Right now, I see files /usr/share/PolicyKit/policy; I guess that's where this kind of thing comes from. How do I override the settings in one of these files? None of them are marked config, so I guess I don't edit them. Are there other places such policy can be set? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 07:30 PM, Seth Vidal wrote: On Wed, 18 Nov 2009, Dennis J. wrote: In fact I agree with you but this doesn't really address my point. How do you make sure the packages that are part of your minimal list don't introduce such a backdoor with the next update? You check them. That's the best you can do. It's just like anything else: How are you sure no one introduces a package into 'updates' which obsoletes glibc? We check them and hope we catch problems. Changing policy is not the same as introducing a problem. There should at least be a process for packages to go through if they want to make changes like PackageKit did so that this kind of thing shows up on peoples radars earlier can be peer-reviewed and if necessary be mentioned in the release-notes. Also these changes should probably not be introduced for updates between releases. My basic point is that changes that allow packages to elevate their privileges should set of some process based formal alarm when they are introduced rather than being discovered by accident after a release. Regards, Dennis -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 09-11-18 13:44:43, nodata wrote: Am 2009-11-18 19:16, schrieb Bruno Wolff III: On Wed, Nov 18, 2009 at 17:45:26 +, Bastien Nocerabnoc...@redhat.com wrote: Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin. This seems pretty reasonable. I don't like the way Fedora is going with this: digging out something that works and saying we'll replace it later makes no sense. Make it work now, or *keep it in*. Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called creative destruction. -- TonyN.:' mailto:tonynel...@georgeanelson.com ' http://www.georgeanelson.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 19:50, schrieb Tony Nelson: On 09-11-18 13:44:43, nodata wrote: Am 2009-11-18 19:16, schrieb Bruno Wolff III: On Wed, Nov 18, 2009 at 17:45:26 +, Bastien Nocerabnoc...@redhat.com wrote: Once we get the new user management stuff into F13 [1], we'd probably tighten that rule so that only admins are given the option, or all users but with the need to authenticate as an admin. This seems pretty reasonable. I don't like the way Fedora is going with this: digging out something that works and saying we'll replace it later makes no sense. Make it work now, or *keep it in*. Fedora has always been this way. Have you tried to use sound or video in the past few releases? I think it's called creative destruction. and ripping out the boot log for several releases... that was the opposite of helpful. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 13:22 -0500, James Antill wrote: 7. And the most obvious one ... how hard is it to get a bad package into one of the repos. that the machine has enabled. Right, PK is counting on this being sufficiently difficult enough to prevent bad things from happening. While I'd like to think that, and would like to say that, I can't. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 01:14 PM, Rahul Sundaram wrote: On 11/18/2009 11:44 PM, Bruno Wolff III wrote: Besides other issues listed, the packages being installed may be privileged programs that the admin doesn't want on the system, may start services or schedule runs at specified times by default which might considered a problem by the admin, the extra packages may use up too much disk space and cause problems. This assumes the user is different from a admin, which is not true for a personal desktop. This revolves back to what the default target audience should be. PackageKit target audience is defined at http://www.packagekit.org/pk-profiles.html If it doesn't match what Fedora wants, then it should be tweaked but the larger question should be addressed first. Rahul Security-relevant defaults aren't set for the common case. They're set for the tightest case. For the desktop user maybe this works fine. For the server user, we've killed our security guarantee completely. It doesn't matter if you can change it. If the system boots so much as once with the default setup it may /already be too late/. By the admin's first opportunity to change the settings the box could already be rooted. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
Am 2009-11-18 19:14, schrieb Rahul Sundaram: On 11/18/2009 11:44 PM, Bruno Wolff III wrote: Besides other issues listed, the packages being installed may be privileged programs that the admin doesn't want on the system, may start services or schedule runs at specified times by default which might considered a problem by the admin, the extra packages may use up too much disk space and cause problems. This assumes the user is different from a admin, which is not true for a personal desktop. This revolves back to what the default target audience should be. PackageKit target audience is defined at http://www.packagekit.org/pk-profiles.html If it doesn't match what Fedora wants, then it should be tweaked but the larger question should be addressed first. Rahul Rahul, it seems to be that the person who made this change (fesco approved?) is the one who should answer why the change is a good thing, rather than oh I changed it, now tell me why it's bad. Do you know who it was? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Simo Sorce sso...@redhat.com: If I have physical access to your machine, I'll own it. I may have to use tools to get to the HDD, but it's only a question of time and dedication. *you* are not one of my users, and this has nothing to do with *you* hacking in my machine. If I have physical access to a machine I do not even care about what's installed on it. In 99% of the cases I will just be able to boot from a live cd. That's a completely different issue. Well, then we're violently agreeing about the same thing. Anyway. It doesn't look like this is a change in Fedora policy, because it clearly caught everyone off-guard. Looks like PK developer made an executive decision and it's up to us to either issue an update to revert to the previous behaviour, or to continue debating whether allowing local console users to install trusted software from trusted repositories is a sane security trade-off. Regards, -- McGill University IT Security Konstantin Ryabitsev Montréal, Québec -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 01:22 PM, James Antill wrote: 3. Are there any attacks due to disk space used? Eg. If /var is low² I can probably install enough pkgs to make logging stop. I'm betting there's still enough systems out there without enough space in /usr for the entire package set. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Casey Dahlin cdah...@redhat.com: On 11/18/2009 01:22 PM, James Antill wrote: 3. Are there any attacks due to disk space used? Eg. If /var is low² I can probably install enough pkgs to make logging stop. I'm betting there's still enough systems out there without enough space in /usr for the entire package set. That's kind of a silly exercise in what-ifs. The default anaconda partition scheme is /boot, swap, and /. If someone wanted to fill up the disk, they can just write to /tmp on a default install. Regards, -- McGill University IT Security Konstantin Ryabitsev Montréal, Québec -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 18 Nov 2009, Konstantin Ryabitsev wrote: 2009/11/18 Casey Dahlin cdah...@redhat.com: On 11/18/2009 01:22 PM, James Antill wrote: 3. Are there any attacks due to disk space used? Eg. If /var is low² I can probably install enough pkgs to make logging stop. I'm betting there's still enough systems out there without enough space in /usr for the entire package set. That's kind of a silly exercise in what-ifs. The default anaconda partition scheme is /boot, swap, and /. If someone wanted to fill up the disk, they can just write to /tmp on a default install. well - except for the 5% reserved for root :) -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, Nov 18, 2009 at 1:48 PM, Chris Adams cmad...@hiwaay.net wrote: It seems the latest way of doing this is via PolicyKit. IMHO all PolicyKit configuration should be secure by default, secure is an meaningless term without reference to a deployment model and threat model, but let's assume here for reference that what you mean is that the shipped RPMs should be configured to not grant any additional privileges over that afforded to the traditional Unix timesharing model, and then the desktop kickstart modifies them. I would agree with that, but it's not trivial. Are we just scoping in PackageKit here, or also consolehelper @console actions? Does it imply removing the setuid bit from /bin/ping? Right now, I see files /usr/share/PolicyKit/policy; I guess that's where this kind of thing comes from. How do I override the settings in one of these files? None of them are marked config, so I guess I don't edit them. Are there other places such policy can be set? See man PolicyKit.conf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Jonathan Underwood jonathan.underw...@gmail.com: Well, it's all a bit inconsistent presently: $ yum install maxima Loaded plugins: presto, refresh-packagekit You need to be root to perform this command. yum isn't PackageKit. Different tools, different feature-sets. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On Wed, 2009-11-18 at 14:11 -0500, Colin Walters wrote: I would agree with that, but it's not trivial. Are we just scoping in PackageKit here, or also consolehelper @console actions? Does it imply removing the setuid bit from /bin/ping? It seem obvious we are talking only about this specific behavior of PackageKit at the moment. Now if it were at least *easy* to revert this behavior ... Take a default F-12 and without much knowledge try to change it (like I would want to do if I had kids). Simo. -- Simo Sorce * Red Hat, Inc * New York -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
2009/11/18 Casey Dahlin cdah...@redhat.com: By the admin's first opportunity to change the settings the box could already be rooted. I'm not sure how you can root a computer from installing signed content by a user that already has physical access to the machine. Richard. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Local users get to play root?
On 11/18/2009 02:10 PM, Seth Vidal wrote: On Wed, 18 Nov 2009, Konstantin Ryabitsev wrote: 2009/11/18 Casey Dahlin cdah...@redhat.com: On 11/18/2009 01:22 PM, James Antill wrote: 3. Are there any attacks due to disk space used? Eg. If /var is low² I can probably install enough pkgs to make logging stop. I'm betting there's still enough systems out there without enough space in /usr for the entire package set. That's kind of a silly exercise in what-ifs. The default anaconda partition scheme is /boot, swap, and /. If someone wanted to fill up the disk, they can just write to /tmp on a default install. well - except for the 5% reserved for root :) -sv Which isn't safe from this since ultimately its root doing the install on the unprivileged user's behalf. --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
