Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
I know that you're not proposing this, but can I just interject that if you make any of these files unreadable by 'other', then supermin appliance building will break. http://libguestfs.org/febootstrap.8.html#supermin_appliances I think supermin appliances are a sufficiently useful mechanism to generate virtual machines / cgroups roots on the fly that we shouldn't break it. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
tis 2010-12-21 klockan 11:47 -0500 skrev Colin Walters: But they still have uid 0, which typical system installation allows root to do things. For example, /bin/sh is 0755 and /bin is also 0755 perms. A disarmed root process can still trojan a system. But what if we got rid of all the read/write permissions for root? Eh? A process given capabilities via file capablities do not need to run with uid 0. It can run as the calling user (no setuid bit), and is what RemoveSETUID is about. For things started as root, a capabilities aware system service started as root can drop to a non-root user while keeping the capabilities it needs. But this is not using file capabilities. But practicaly nothing accessed bu users should be running as root. Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
tis 2010-12-21 klockan 18:52 -0500 skrev i.g...@comcast.net: Ok, so who says that the files must be owned by root? Make them owned by some other user -- say, bin? (or does that have another use that my google search isn't coming up with?) Better to make the process not run as root imho. Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
ons 2010-12-22 klockan 00:59 +0100 skrev Miloslav Trmač: This is possible, but it would be a much larger change to the system. To take a particular example, look at /etc/shadow. It needs to be protected against attackers, so it should not be owned by root - let's make it owned by adm, say. Imho in that specific case it should be protected by two group acls. One group for writing/modifying, another for reading. No need for capabilities at all, just setgroupid and file acls. shadow have no special significance to kernel functions. Regards Henrik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
Pardon the thread necromancy, So recently I had cause to look at http://fedoraproject.org/wiki/Features/RemoveSETUID again (I was investigating the X server permissions for an unrelated reason). Now, that page links to http://people.redhat.com/sgrubb/libcap-ng/index.html which attempts to explain the value of capabilities, etc. I was following along on all of this, and I understand that capabilities have some (non-negligible) value if you don't have e.g. cap_sys_admin. But then I got to the point where it says: But they still have uid 0, which typical system installation allows root to do things. For example, /bin/sh is 0755 and /bin is also 0755 perms. A disarmed root process can still trojan a system. But what if we got rid of all the read/write permissions for root? So...right, we can do these small changes, and then if we do this BIG CHANGE, it all works!. But this feature doesn't include BIG CHANGE, and there are no plans to, right? Or is chmod u-rwx g-rwx on the root filesystem really in the cards? Now, https://fedoraproject.org/wiki/Features/LowerProcessCapabilities appears to claim 100% completion on this for Fedora 12, but none (?) of it happened? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/21/2010 11:47 AM, Colin Walters wrote: Pardon the thread necromancy, So recently I had cause to look at http://fedoraproject.org/wiki/Features/RemoveSETUID again (I was investigating the X server permissions for an unrelated reason). Now, that page links to http://people.redhat.com/sgrubb/libcap-ng/index.html which attempts to explain the value of capabilities, etc. I was following along on all of this, and I understand that capabilities have some (non-negligible) value if you don't have e.g. cap_sys_admin. But then I got to the point where it says: But they still have uid 0, which typical system installation allows root to do things. For example, /bin/sh is 0755 and /bin is also 0755 perms. A disarmed root process can still trojan a system. But what if we got rid of all the read/write permissions for root? So...right, we can do these small changes, and then if we do this BIG CHANGE, it all works!. But this feature doesn't include BIG CHANGE, and there are no plans to, right? Or is chmod u-rwx g-rwx on the root filesystem really in the cards? Now, https://fedoraproject.org/wiki/Features/LowerProcessCapabilities appears to claim 100% completion on this for Fedora 12, but none (?) of it happened? File capabilities just limit the number of capabilities an application starts with. setuid app means an app starts with all 32, a couple of new ones, capabilities. Then it is up to the app developer to drop the capabilities when the app is done using them. Going to file capabilities just limits the capabilities an application starts with to the specified capabilities. The application developer should still drop the capabilities once they no longer need them. It helps in the case of a bug in an application, that does not drop capabilities. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0RDDUACgkQrlYvE4MpobNKdwCffTSEd/nmN/pwtG1d6JUdUmA6 FgwAnRK1eNQ53yLjIDwnCyFEJN4HDiF2 =1ypa -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
On Tue, Dec 21, 2010 at 3:21 PM, Daniel J Walsh dwa...@redhat.com wrote: File capabilities just limit the number of capabilities an application starts with. setuid app means an app starts with all 32, a couple of new ones, capabilities. Then it is up to the app developer to drop the capabilities when the app is done using them. Going to file capabilities just limits the capabilities an application starts with to the specified capabilities. The application developer should still drop the capabilities once they no longer need them. It helps in the case of a bug in an application, that does not drop capabilities. I understand the goal of getting fewer capabilities (however, I think switching setuid to cap_sys_admin is at best pointless, at worst an obfuscation). But you didn't answer my question - does the scope of this plan include a Unix mode 005 /bin, etc. or not? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/21/2010 03:50 PM, Colin Walters wrote: On Tue, Dec 21, 2010 at 3:21 PM, Daniel J Walsh dwa...@redhat.com wrote: File capabilities just limit the number of capabilities an application starts with. setuid app means an app starts with all 32, a couple of new ones, capabilities. Then it is up to the app developer to drop the capabilities when the app is done using them. Going to file capabilities just limits the capabilities an application starts with to the specified capabilities. The application developer should still drop the capabilities once they no longer need them. It helps in the case of a bug in an application, that does not drop capabilities. I understand the goal of getting fewer capabilities (however, I think switching setuid to cap_sys_admin is at best pointless, at worst an obfuscation). But you didn't answer my question - does the scope of this plan include a Unix mode 005 /bin, etc. or not? No -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0RF50ACgkQrlYvE4MpobP4lwCgjvFcXjpCq1BdjawVQOC6uHfL kjwAoJ9A6lAIjLnhft+mpb4n3feZjuuw =0JZe -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
Colin Walters píše v Út 21. 12. 2010 v 11:47 -0500: But they still have uid 0, which typical system installation allows root to do things. For example, /bin/sh is 0755 and /bin is also 0755 perms. A disarmed root process can still trojan a system. But what if we got rid of all the read/write permissions for root? So...right, we can do these small changes, and then if we do this BIG CHANGE, it all works!. But this feature doesn't include BIG CHANGE, and there are no plans to, right? No. The original plans didn't count with the fact that changing permissions by owner does not require any capabilities either. If an attacker were controlling a process running with uid 0 and no capabilities at all, and /bin/sh were 0555, nothing prevents the attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes any attempts to change the file permissions rather pointless. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
2010/12/21 Miloslav Trmač m...@volny.cz: If an attacker were controlling a process running with uid 0 and no capabilities at all, and /bin/sh were 0555, nothing prevents the attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes any attempts to change the file permissions rather pointless. Ah, of course. That makes sense, thanks! But it leaves me feeling pretty uncertain about the value of trying to subset capabilities... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
On Tue, Dec 21, 2010 at 10:37:44PM +0100, Miloslav Trmač wrote devel: Colin Walters píše v Út 21. 12. 2010 v 11:47 -0500: But they still have uid 0, which typical system installation allows root to do things. For example, /bin/sh is 0755 and /bin is also 0755 perms. A disarmed root process can still trojan a system. But what if we got rid of all the read/write permissions for root? So...right, we can do these small changes, and then if we do this BIG CHANGE, it all works!. But this feature doesn't include BIG CHANGE, and there are no plans to, right? No. The original plans didn't count with the fact that changing permissions by owner does not require any capabilities either. If an attacker were controlling a process running with uid 0 and no capabilities at all, and /bin/sh were 0555, nothing prevents the attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes any attempts to change the file permissions rather pointless. Ok, so who says that the files must be owned by root? Make them owned by some other user -- say, bin? (or does that have another use that my google search isn't coming up with?) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
i.g...@comcast.net píše v Út 21. 12. 2010 v 18:52 -0500: On Tue, Dec 21, 2010 at 10:37:44PM +0100, Miloslav Trmač wrote devel: Colin Walters píše v Út 21. 12. 2010 v 11:47 -0500: But they still have uid 0, which typical system installation allows root to do things. For example, /bin/sh is 0755 and /bin is also 0755 perms. A disarmed root process can still trojan a system. But what if we got rid of all the read/write permissions for root? So...right, we can do these small changes, and then if we do this BIG CHANGE, it all works!. But this feature doesn't include BIG CHANGE, and there are no plans to, right? No. The original plans didn't count with the fact that changing permissions by owner does not require any capabilities either. If an attacker were controlling a process running with uid 0 and no capabilities at all, and /bin/sh were 0555, nothing prevents the attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes any attempts to change the file permissions rather pointless. Ok, so who says that the files must be owned by root? Make them owned by some other user -- say, bin? (or does that have another use that my google search isn't coming up with?) This is possible, but it would be a much larger change to the system. To take a particular example, look at /etc/shadow. It needs to be protected against attackers, so it should not be owned by root - let's make it owned by adm, say. On the other hand, passwd(1) should be able to modify it, so passwd(1) should be set-uid adm, not root. On the other hand, PAM pretty strongly assumes that is is running as root - it is full of setuid() and other system calls that are root-only, and arbitrary PAM modules may, and often do, assume that they are running as root, therefore passwd(1) should be set-uid root. See the problem? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
2010/12/21 Miloslav Trmač: If an attacker were controlling a process running with uid 0 and no capabilities at all, and /bin/sh were 0555, nothing prevents the attacker from chmod()ing /bin/sh to 0755 and overwriting it. This makes any attempts to change the file permissions rather pointless. You don't even need to change permissions for root to be able to delete or change the contents of the directory. Dick -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
On Mon, 01.11.10 20:28, Richard W.M. Jones (rjo...@redhat.com) wrote: On Mon, Nov 01, 2010 at 07:19:15PM +, Paul Howarth wrote: Any suggestions? We've encountered some funny things about tmpfs before: It doesn't support O_DIRECT at all, for example, necessitating workarounds in libguestfs/qemu. Just speculating, but maybe it doesn't support extended attributes, or has only partial support for them? tmpfs as of now does not support user xattrs. Only SELinux labels are supported. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
On 29/10/10 04:15, Jason L Tibbitts III wrote: JN == Joe Nallj...@nall.com writes: JN On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote: More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden capabilities are present on a binary? 'ls' doesn't mention anything. JN getcap Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages. I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it. I've just come across another issue with this. I use the tmpfs plugin with mock usually, and it appears that tmpfs doesn't support the necessary file capabilities, as I get these errors when setting up the buildroot: DEBUG util.py:267: Error unpacking rpm package iputils-20101006-2.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported DEBUG util.py:267: Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported If I disable the tmpfs plugin, so mock uses the ext3 filesystem I have on /var/lib/mock, the build succeeds. So at least I have a workaround but I'd like to have tmpfs working as it *really* improves performance. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/01/2010 09:44 AM, Paul Howarth wrote: On 29/10/10 04:15, Jason L Tibbitts III wrote: JN == Joe Nallj...@nall.com writes: JN On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote: More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden capabilities are present on a binary? 'ls' doesn't mention anything. JN getcap Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages. I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it. I've just come across another issue with this. I use the tmpfs plugin with mock usually, and it appears that tmpfs doesn't support the necessary file capabilities, as I get these errors when setting up the buildroot: DEBUG util.py:267: Error unpacking rpm package iputils-20101006-2.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported DEBUG util.py:267: Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported If I disable the tmpfs plugin, so mock uses the ext3 filesystem I have on /var/lib/mock, the build succeeds. So at least I have a workaround but I'd like to have tmpfs working as it *really* improves performance. Paul. Paul is this because NOSUID is set on tmpfs? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzO1ukACgkQrlYvE4MpobNTRgCgvpFXeGWful7wY1np4buMLBrc 1zEAoNIBDFDHQ9t8qoqljX9pRlACOUFS =27qj -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
On Mon, 01 Nov 2010 11:04:09 -0400 Daniel J Walsh dwa...@redhat.com wrote: On 11/01/2010 09:44 AM, Paul Howarth wrote: On 29/10/10 04:15, Jason L Tibbitts III wrote: JN == Joe Nallj...@nall.com writes: JN On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote: More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden capabilities are present on a binary? 'ls' doesn't mention anything. JN getcap Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages. I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it. I've just come across another issue with this. I use the tmpfs plugin with mock usually, and it appears that tmpfs doesn't support the necessary file capabilities, as I get these errors when setting up the buildroot: DEBUG util.py:267: Error unpacking rpm package iputils-20101006-2.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported DEBUG util.py:267: Error unpacking rpm package policycoreutils-2.0.83-32.fc15.x86_64 DEBUG util.py:267: error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported If I disable the tmpfs plugin, so mock uses the ext3 filesystem I have on /var/lib/mock, the build succeeds. So at least I have a workaround but I'd like to have tmpfs working as it *really* improves performance. Paul. Paul is this because NOSUID is set on tmpfs? The tmpfs is set up by mock and I can't see anywhere in the mock code that it sets nosuid. I can't tell from outside mock what options it's using as it also uses a namespace. If I just run mount from within a package build I don't get any output. Any suggestions? Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
On Mon, Nov 01, 2010 at 07:19:15PM +, Paul Howarth wrote: Any suggestions? We've encountered some funny things about tmpfs before: It doesn't support O_DIRECT at all, for example, necessitating workarounds in libguestfs/qemu. Just speculating, but maybe it doesn't support extended attributes, or has only partial support for them? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
On Thu, 28 Oct 2010, Jason L Tibbitts III wrote: JN == Joe Nall j...@nall.com writes: JN On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote: More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden capabilities are present on a binary? 'ls' doesn't mention anything. JN getcap Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages. I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it. Yup, rpm 4.7.0 was the first one to support file capabilities. It's use is tracked with rpmlib(FileCaps) dependency, making packages utilizing the feature uninstallable with any older rpm versions, and of course trying to build such packages on older versions will barf out with a errors. It should be possible to have EPEL define a macro that turns %caps(foo) into an %attr() with SUID bit set, but blindly enabling SUID bits might not be such a hot idea... - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RemoveSETUID feature (Was: Summary/Minutes from today's FESCo meeting (2010-10-26) NEW TIME!)
JN == Joe Nall j...@nall.com writes: JN On Oct 28, 2010, at 5:08 PM, Richard W.M. Jones wrote: More to the point, I can easily see the setuid bit easily on a binary. How do I tell if these strange/hidden capabilities are present on a binary? 'ls' doesn't mention anything. JN getcap Interesting. That's in the libcap package, which is sort of oddly named because it includes executables. And of course it's multilib, but the binaries are arch-specific which I believe is a multilib conflict. Probably needs the executables split out into a libcap-tools packages. I notice that rpm supports that %caps() directive in the %files list to specify capabilities. I don't recall seeing that before; how long ago did rpm grow support for it? It looks like it came in around rpm 4.7, so all supported Fedora releases have it. However, I'm certain it's not in RHEL4 and I'm pretty sure it's not in RHEL5 either, so at least the EPEL folks will need to make a note of it. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
