Re: Add extra generated RPM requires - how?
On Friday 18 December 2009 03:54:53 pm Adam Jackson wrote:
> On Fri, 2009-12-18 at 20:26 +, Richard W.M. Jones wrote:
> > For libguestfs [RHBZ#547496] I want to add some extra 'Requires'
> > dependencies by running a shell script over a particular file that
> > gets generated during the build.
> >
> > What's the best way, or a way, to do this?
>
> It's... not easy. You want to overload the %__find_provides macro to
> invoke your script as well as the standard script for things like
> library sonames.
I used something like this:
#%_use_internal_dependency_generator 0
#%__find_requires /home/sgrubb/bin/find-requires
and then ran a shell script that had this piece in it where $1 was a file
suspected of being a bash script by running the file command. Since people have
a habit of using a script name and not its full path, it uses which to resolve
the full path. This might be better done using the full rpm database that yum
operates off of. Anyways...this was the core of it:
# Then check its requirements
cmds=`/bin/bash --rpm-requires "$1" | sort | uniq | tr '()' ' ' | awk '{ print
$2 }'`
for c in $cmds
do
tgt=`which $c 2>/dev/null`
if [ x"$tgt" = x ] ; then
echo "$c cannot be resolved" 1>&2
continue
fi
tmp_r="`rpm -qf $tgt`"
if [ $? -eq 0 -a $RPM -eq 1 ] ; then
# Only use good results for rpms
r="$r\n$tmp_r"
else
r="$r\n$tgt"
fi
done
echo -e $r | sort | uniq
exit 0
-Steve
--
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 Wednesday 18 November 2009 04:45:05 pm James Antill wrote: > On Wed, 2009-11-18 at 16:04 -0500, Steve Grubb wrote: > > > The problem is the *Default* not the fact that you can consciously > > > allow users to update without a password. > > > > And I wonder what the audit trail will show? Does it show which user > > installed these packages? > > PK has it's own logging, it logs the user the API is running from > there. But it doesn't set loginuid, so "yum history", auditd, SELinux, > etc. don't know. That is a big problem. If I have the following audit rule: -a always,exit -F dir=/usr -F perm=w It needs to show which user was able to write into /usr or the audit trail is broken. -Steve -- 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 Wednesday 18 November 2009 01:35:30 pm Simo Sorce wrote: > 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. I agree with this sentiment. It would be a huge surprise for setuid apps to suddenly start showing up on boxes. > The problem is the *Default* not the fact that you can consciously allow > users to update without a password. And I wonder what the audit trail will show? Does it show which user installed these packages? -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-10-02
On Wednesday 07 October 2009 06:16:50 pm Matthias Clasen wrote: > On Wed, 2009-10-07 at 17:11 -0400, Steve Grubb wrote: > > On Friday 02 October 2009 01:56:21 pm Jon Stanley wrote: > > > Meeting summary > > > --- > > > * incomplete features (jds2001, 17:04:12) > > > > > > * AGREED: Lower Process Capabilities is retained, dbus changes are > > > being committed to complete the feature. (jds2001, 17:38:58) > > > > I'm wondering if this is still in work? I just checked koji and dbus was > > rebuilt today, but without applying the patch here: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=518541 > > > > I really want to mark this feature 100% done. All that needs to be done > > is change the BuildRequires to libcap-ng-devel and apply the attached > > patch. > > I just asked Colin, who looked at the patch. > There must have been some miscommunication, since he had expected you to > do the build for F12 Sometime earlier this year something was changed in the package db that requires you to be a proven packager to touch other people's packages. I found this out when I tried to rebuild all the dependencies for the audit-libs soname number bump back in August. > ...let me do a build now. Thanks. The Lower Process Capabilities Feature is now 100% complete. Wiki page has been updated. The testing plan has been updated. Now we just need testing. :) -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo meeting summary for 2009-10-02
On Friday 02 October 2009 01:56:21 pm Jon Stanley wrote: > Meeting summary > --- > * incomplete features (jds2001, 17:04:12) > * AGREED: Lower Process Capabilities is retained, dbus changes are > being committed to complete the feature. (jds2001, 17:38:58) I'm wondering if this is still in work? I just checked koji and dbus was rebuilt today, but without applying the patch here: https://bugzilla.redhat.com/show_bug.cgi?id=518541 I really want to mark this feature 100% done. All that needs to be done is change the BuildRequires to libcap-ng-devel and apply the attached patch. Thanks, -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Switching to Native Upstart Scripts?
On Friday 02 October 2009 02:42:43 pm Bill Nottingham wrote: > enforcing dependencies between SysV and upstart scripts - if a package > that provides a service that a SysV service depends on (via LSB headers) > changes to an upstart script, things go wrong. Also last time I checked, they still have not specified an audit facility. They have one for syslog, but not audit. And yes this matters. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
On Saturday 19 September 2009 07:25:13 pm Matej Cepl wrote: > Steve Grubb, Fri, 18 Sep 2009 08:24:18 -0400: > > I also think that the reason xinetd came into existence in the first > > place has long since passed. > > Do you think that Fedora should humbly return with a cap in hand to inetd? Not at all. These days the only need for xinetd is in memory constrained systems. For mainline x86_64 bought with typically 4Gb of main memory, xinetd is a thing of the past. That's my point. If more work is done on xinetd, the new devs should think about how much memory any new feature would add. I would look at the functions in the lib directory and scuttle anything I could to make xinetd smaller and more memory efficient. I wanted to do some of this in the past where it could use native glibc functionality on Linux and portable functions elsewhere. But the project leader wanted to use compat functions on all platforms so any bug reports aren't platform specific. In any new development, I would forgo supporting the Cray, SunOS, and True64 in favor of smaller footprint on modern OS. They can still use the old xinetd. xinetd could be put on a diet and made better. For example, the ident protocol is useless from a security PoV. All that code could be dropped. The config parser is huge. That code could be dlopened and then dropped once the daemon is running. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: selinux hasn't been running for over a week
On Friday 18 September 2009 12:39:57 pm Tomasz Torcz wrote: > On Fri, Sep 18, 2009 at 12:03:05PM -0400, Steve Grubb wrote: > > On Thursday 17 September 2009 05:29:02 pm Steve Grubb wrote: > > > If selinux is not disabled and it does not become permissive or > > > enforcing, it has to get logged and optionally shutdown the system. > > > > > > Aside from no logging, any ideas why selinux no longer works? > > > > A few minutes ago, I updated to the new dracut in rawhide & then I > > updated everything else which updated the kernel and presumably build a > > new initrd. Now, with the new dracut there is some logging which helps > > diagnose the problem: > > > > dracut: Loading SELinux policy > > dracut: SELinux: Could not load policy file > > /etc/selinux/targeted/policy/policy.24: Invalid argument > > dracut: /sbin/load_policy: Can't load policy: Invalid argument > > > > So...where does this lead us? > > When updating through yum today I saw something about wrong > module for ModemManager or NetworkManager. I haven't written down > exact message, but I hope that helps. Yeah, saw that too, but that was fixed with libsemanage update. > And yes, dracut message is not helping at all. Maybe "dmesg" > output carry more info and should be displayed also? This was from dmesg, so its now being logged. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: selinux hasn't been running for over a week
On Thursday 17 September 2009 05:29:02 pm Steve Grubb wrote: > If selinux is not disabled and it does not become permissive or enforcing, > it has to get logged and optionally shutdown the system. > > Aside from no logging, any ideas why selinux no longer works? A few minutes ago, I updated to the new dracut in rawhide & then I updated everything else which updated the kernel and presumably build a new initrd. Now, with the new dracut there is some logging which helps diagnose the problem: dracut: Loading SELinux policy dracut: SELinux: Could not load policy file /etc/selinux/targeted/policy/policy.24: Invalid argument dracut: /sbin/load_policy: Can't load policy: Invalid argument So...where does this lead us? -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: selinux hasn't been running for over a week
On Friday 18 September 2009 09:54:12 am Daniel J Walsh wrote: > >> If the kernel has SELinux and it is not in permissive mode, it should > >> execute load_policy > > Yes in permissive mode load_policy will return 2 if it can not load policy. > I guess dracut should also look in /etc/selinux/config to see if the > SELINUX environment variable is not set to enforcing. What about interaction with the kernel command line? What the kernel was given is listed in /proc/cmdline. iow, if I boot with selinux=0 and the config says enabled, shouldn't the kernel command line take priority? > > You mean if the machine is in permissive mode, it should load_policy, but > > not crash. But it should log the reason so it can be debugged. > > > >> Load_policy will exit with 0 on success or 2 on failure and SELinux in > >> permissive mode. > > > > And if chroot fails, we need to handle it. > > This will probably crash anyways In the code I looked at, only if it returned 3... -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: selinux hasn't been running for over a week
Hi, Just a couple clarifications for anyone implementing this. On Friday 18 September 2009 07:34:29 am Daniel J Walsh wrote: > Bottom line is a bug in the dracut scripts. The scripts should execute > load_policy and if for ANY reason load_policy fails and the machine is in > enforcing mode the machine needs to crash. (It should also log the > error). > > If the kernel has SELinux and it is not in permissive mode, it should > execute load_policy You mean if the machine is in permissive mode, it should load_policy, but not crash. But it should log the reason so it can be debugged. > Load_policy will exit with 0 on success or 2 on failure and SELinux in > permissive mode. And if chroot fails, we need to handle it. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
On Friday 18 September 2009 08:34:03 am Ralf Ertzinger wrote: > Hi. > > On Fri, 18 Sep 2009 08:24:18 -0400, Steve Grubb wrote: > > I also think that the reason xinetd came into existence in the first > > place has long since passed. The original intent was to save memory > > by not having half a dozen servers running. (Remember the early > > 1990's systems.) Today we have plenty of memory in computers and the > > reason for xinetd is gone. > > I always thought that one reason for xinetd was the capability of running > network servers without actually having any network code in the server. Its network code, it just doesn't do listen/accept. :) Of course xinetd also takes care of restricting access a number of ways like time of day , network, tcp_wrappers, and setting up the uid/group... Something I forgot to mention earlier, even though I give up any interest in xinetd, you should contact Rob Braun who is the maintainer and verify he has no more interest. I cannot speak for him. Also, another bug that appears sometimes...xinetd has a builtin daytime service. It follows RFC867, which says there is no syntax for the daytime protocol and its use is for *debugging*. It also lists 2 popular formats. Xinetd follows one of the 2 listed, and HPUX / AIX (and likely others) follow the other one. If the RFC were better specified, there would be no conflict. Xinetd's daytime implementation goes back more than 10 years so its got a lot of history in its current format and should stay the default. So, maybe there should be a config option to specify one format or the other for interoperability. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Xinetd resurrection
On Friday 18 September 2009 06:04:43 am Jan Safranek wrote: > Don't forget to announce the fork on xinetd mailing list. Its dead. > Also, contacting orginal xinetd maintainer if he is willing to contribute, > e.g. with xinetd.org domain :). I am/was the co-maintainer of xinetd. I hearby relinquish all interest in xinetd. I have more than enough projects to keep me busy. I also think that the reason xinetd came into existence in the first place has long since passed. The original intent was to save memory by not having half a dozen servers running. (Remember the early 1990's systems.) Today we have plenty of memory in computers and the reason for xinetd is gone. A note to anyone taking this on. We had people running xinetd on very old hardware and they expected it to work. If you are going to drop support for the old systems, you might want to name the project xinetd-ng or something to signify that its not the same old code. Also, you can cleanhouse with that portable library and other crazy stuff in the lib directory. There is one serious bug in xinetd that needs fixing that you might want to address. If you have a "wait" service, xinetd does not accept the connection - this is by design. It passes the descriptor for the connection to the child which is required to accept the connection before using the socket. If that program does not accept the connection, it likely cannot read anything and will exit. Xinetd re-enables the listening descriptor and sees the same descriptor in ready state and spawns the same child to handle it. Round and round we go eating up CPU. There needs to be kernel support for looking at a descriptor and seeing its state so that this problem can be handled gracefully. As far as I know, this problem is unique to inetd programs since they pass descriptors to other programs for use. I also think you might want to contact people in altlinux or openwall and see if they are interested in this new project. They expressed some interest in the past - especially if the code footprint can be reduced. They want a smaller, leaner xinetd. Good Luck... -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: selinux hasn't been running for over a week
On Thursday 17 September 2009 09:39:48 pm Yuan Yijun wrote: > > What's happened in our rawhide boot sequence that cause selinux to not be > > running anymore? Selinux is not disabled in the grub.conf kernel line and > > sestatus shows its disabled. There is nothing in the system logs saying > > that there was a problem. > > I encountered this problem as well, but don't know why. It happens > when I am trying different kernels among some recent builds (starting > from 0.104 to 1.14). I guess there is a incompatible between older > kernels and the policy; when you install a kernel while SELinux is > disabled, it may cause future problems. Do you expect SELinux to be > enabled automatically? Yes I do. I have not disabled selinux in any of the configuration. > I usually enable SELinux by doing a relabel, then install the kernel again. relabeling is totally different than the system not having it enabled at all when its supposed to. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: selinux hasn't been running for over a week
On Thursday 17 September 2009 05:42:46 pm Jason L Tibbitts III wrote: > SG> What's happened in our rawhide boot sequence that cause selinux > SG> to not be running anymore? > > The issue is having a separate /usr, which for some reason has recently > become a bad thing to do. I believe the relevant binaries are moving up > one level (from /usr/bin to /bin, or whatever) in order to fix this > issue. I don't have a separate /usr partition. And looking at the code in /usr/share/dracut/modules/d/99base/selinux- loadpolicy.sh, it only crashes if ret = 3. What if the return code was 1 indicating a failure? How do you look at what's supposed to be in the initrd to see if something is wrong inside it? I opened a bz 524113 for this. But I'm surprised this wasn't mentioned on the list before. :) -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
selinux hasn't been running for over a week
hi, What's happened in our rawhide boot sequence that cause selinux to not be running anymore? Selinux is not disabled in the grub.conf kernel line and sestatus shows its disabled. There is nothing in the system logs saying that there was a problem. If selinux is not disabled and it does not become permissive or enforcing, it has to get logged and optionally shutdown the system. Aside from no logging, any ideas why selinux no longer works? Thanks, -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: what features are required in Fedora kernel
On Friday 04 September 2009 02:17:10 pm Dan Horák wrote: > I am building kernels for some ARM based devices that use Fedora/ARM as > user-land. Glad to see someone else looking at the ARM kernel. > These devices are usually very limited in the size of kernel > that can be stored in their flash memories (like 2MB kernel, 4MB > ramdisk). So I would like to know what kernel features make a "Fedora > kernel", what are the MUST HAVE features? Maybe some usb devices. Which ones...I don't know. :) > Now I have those on my list > - audit Note that the audit system on ARM is dysfunctional. No one has ever taken the time to write the requisite code in arch/arm/kernel/ptrace.c to call audit_syscall_entry(). Without that code upstream (or as a patch), the audit system is limited to user space originating events. I don't know if SE Linux AVC's are affected by the audit system not having its hands on a lot of information during the syscall. > - SELinux > - IPv6 > - Netfilter for both IPv4 and IPv6 Netfilter is needed badly on that arch since the default system image has a mail server listening to the public IP address and running as root. Iptables is needed to block this access. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: clang static analyzer: use it!
On Friday 04 September 2009 02:30:14 am Jim Meyering wrote: > Quick summary: use this tool: > > http://clang-analyzer.llvm.org/ > > If you're not using its "scan-build" tool, then start. Right now. > Really. It's that good. llvm is in Fedora. Looking at the build instructions for clang, it seems like it would naturally fit as a subpackage for llvm. So, getting it into Fedora should not be too much to do since llvm is already approved. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaning packages
On Friday 21 August 2009 04:34:24 pm Aurelien Bompard wrote: > - ulogd -- The userspace logging daemon for netfilter I'm taking this one. Thanks, -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: soname number bump for audit-libs
On Monday 10 August 2009 12:32:10 pm Steve Grubb wrote: > I wanted to let everyone know that I will be pushing audit-2.0 into rawhide > in the next day or two. It will change the version number of libaudit. The > following packages are known to have dependencies on audit-libs: Just a quick reminder that I'll start into this now that Alpha Freeze is over. If you don't want me to touch a package on this list, let me know soon. Thanks, -Steve > repoquery --repoid=rawhide --whatrequires --alldeps > 'libaudit.so.0()(64bit)' | grep x86_64 > > cups-1:1.4-0.rc1.12.fc12.x86_64 > xorg-x11-server-Xorg-0:1.6.99-28.20090804.fc12.x86_64 > shadow-utils-2:4.1.4.1-6.fc12.x86_64 > dbus-1:1.2.16-4.fc12.x86_64 > cups-libs-1:1.4-0.rc1.12.fc12.x86_64 > cups-lpd-1:1.4-0.rc1.12.fc12.x86_64 > xorg-x11-server-Xvfb-0:1.6.99-28.20090804.fc12.x86_64 > frysk-gnome-0:0.4-11.fc12.x86_64 > readahead-1:1.4.9-3.fc12.x86_64 > cronie-0:1.4-3.fc12.x86_64 > util-linux-ng-0:2.16-3.fc12.x86_64 > nscd-0:2.10.90-12.x86_64 > xorg-x11-server-Xnest-0:1.6.99-28.20090804.fc12.x86_64 > policycoreutils-newrole-0:2.0.68-1.fc12.x86_64 > passwd-0:0.76-3.fc12.x86_64 > gdm-1:2.27.4-4.fc12.x86_64 > openssh-server-0:5.2p1-17.fc12.x86_64 > anaconda-0:12.7-1.fc12.x86_64 > sudo-0:1.7.1-5.fc12.x86_64 > frysk-devel-0:0.4-11.fc12.x86_64 > frysk-0:0.4-11.fc12.x86_64 > xorg-x11-server-Xephyr-0:1.6.99-28.20090804.fc12.x86_64 > upstart-0:0.3.11-2.fc12.x86_64 > cups-php-1:1.4-0.rc1.12.fc12.x86_64 > policycoreutils-0:2.0.68-1.fc12.x86_64 > libxf86config-0:1.6.99-28.20090804.fc12.x86_64 > ipsec-tools-0:0.7.2-3.fc12.x86_64 > amtu-0:1.0.8-1.fc12.x86_64 > pam-0:1.1.0-3.fc12.x86_64 > aide-0:0.13.1-10.fc12.x86_64 > rsh-server-0:0.17-55.fc12.x86_64 > > I can rebuild all these against the new audit package. If you would rather > me not touch your package, just let me know. > > Thanks, > -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rawhide report: 20090819 changes
On Wednesday 19 August 2009 08:40:52 am Rawhide Report wrote: > Compose started at Wed Aug 19 06:15:07 UTC 2009 > > New package Does this large list mean that the Alpha freeze is lifted? -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Friday 14 August 2009 06:05:06 pm Serge E. Hallyn wrote:
> Quoting Steve Grubb (sgr...@redhat.com):
> > On Sunday 26 July 2009 07:32:36 pm Steve Grubb wrote:
> > A sample srpm can be found here for anyone wanting to try it out before
> > alpha is unfrozen.
> >
> > http://people.redhat.com/sgrubb/files/filesystem-2.4.24-1.fc12.src.rpm
> >
> > Any feedback would be appreciated.
>
> downloading and looking at filesystem.spec in the above rpm, I don't
> see any special treatment for boot, root, or /lib Is the right
> rpm at that link?
Should be. this morning I found that I forgot the /usr/lib[64] directories and
updated my local copy. I just updated the file I linked to above.
rpm -qpl --verbose seems to show me that the changes are in place. I also
added tracker bugs to the project page so people can better tell what was
patched and how it might have been modified. In any event the patch attached to
bz is below. I only change the attributes and not the main code.
-Steve
--- filesystem.orig/filesystem.spec 2009-07-25 11:07:17.0 -0400
+++ filesystem/filesystem.spec 2009-08-14 13:09:19.0 -0400
@@ -79,15 +79,17 @@
%files -f filelist
%defattr(0755,root,root)
-%dir /
-/bin
-/boot
+%dir %attr(555,root,root) /
+%attr(555,root,root) /bin
+%attr(555,root,root) /boot
/dev
/etc
/home
-/lib
+%attr(555,root,root) /lib
+%attr(555,root,root) /usr/lib
%ifarch x86_64 ppc ppc64 sparc sparc64 s390 s390x
-/%{_lib}
+%attr(555,root,root) /%{_lib}
+%attr(555,root,root) /usr/%{_lib}
%endif
/media
%dir /mnt
@@ -95,15 +97,16 @@
%ghost %config(missingok) %verify(not size md5 mode user link rdev group
mtime) /mnt/floppy
%dir /opt
%attr(555,root,root) /proc
-%attr(750,root,root) /root
-/sbin
+%attr(550,root,root) /root
+%attr(555,root,root) /sbin
/selinux
/srv
/sys
%attr(1777,root,root) /tmp
%dir /usr
/usr/[^s]*
-/usr/sbin
+%attr(555,root,root) /usr/sbin
+%attr(555,root,root) /usr/bin
%dir /usr/share
/usr/share/applications
/usr/share/augeas
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Thursday 13 August 2009 05:53:37 pm John Poelstra wrote: > Can you update the feature page to reflect the reduced scope of the > feature and its completion percentage? All I see since FESCo met was > the change to the detailed description related to the permissions. That *is* the reduction in scope - other than what I have time to actually work on. If I can fix dhcp, that is a major win. That is the item that stands out as the biggest problem when running netcap. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Sunday 26 July 2009 07:32:36 pm Steve Grubb wrote: > What can be done is that we program the application to drop some of the > capabilities so that its not all powerful. There's just one flaw in this > plan. The directory for /bin is 0755 root root. So, even if we drop all > capabilities, the root acct can still trojan a system. > > If we change the bin directory to 005, then root cannot write to that > directory unless it has the CAP_DAC_OVERRIDE capability. The idea with this > project is to not allow network facing or daemons have CAP_DAC_OVERRIDE, > but to only allow it from logins or su/sudo. As discussed at the Fesco meeting last week, the lower process capabilities project is going to reduce the scope of this part of the proposal. At this point, we are going to tighten up perms on the directories in $PATH, /lib[64], /boot, and /root. A sample srpm can be found here for anyone wanting to try it out before alpha is unfrozen. http://people.redhat.com/sgrubb/files/filesystem-2.4.24-1.fc12.src.rpm Any feedback would be appreciated. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: soname number bump for audit-libs
On Monday 10 August 2009 02:02:47 pm Jason L Tibbitts III wrote: > >>>>> "SG" == Steve Grubb writes: > > SG> It would have been in before feature freeze if sc-audit hadn't > SG> gotten stuck in package review. > > A couple of points here, since you seem to be blaming the review > process for the lateness of this package: > > Submitting a new package request and expecting it to be reviewed in > under a week is simply not reasonable. I was doing the package review and someone else took it from me. I knew the deadline and that we were splitting sc-audit into its own package during this release. The person that took the review from me seemed to be interested in it and Mirek created a new package real fast. There just wasn't follow up after the new package was created. I could have taken the package review back, I suppose. But I didn't want to seem rude. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: soname number bump for audit-libs
On Monday 10 August 2009 01:04:32 pm Jesse Keating wrote: > > OK, fine. I'll wait until after the Alpha freeze is over. > > > Even after that one has to wonder, why is a change like this going in > after the feature freeze. It would have been in before feature freeze if sc-audit hadn't gotten stuck in package review. > How big of an ABI change is this, will there have to be any porting effort, > what's the risk, what's the gain? Should be little risk. This removes the old API needed for communicating with kernels before the 2.6.16 kernel was released. Somewhere around 2.6.22 libaudit made the old API hard to use. It was still there for anything linking to it. I have not looked in detail at all the packages on the dependency list but the changes only affect the audit rule setting interface and not the logging interface. Auditctl is likely to be the only program affected by the change, but to be safe and make sure nothing falls through the cracks, the number is bumped. Almost all apps are using the logging interface and are not affected. If anything actually is sending audit rules, the porting is trivial. You just use the _data equivalent function and use the audit_rule_data structure to hold your rules. The gain is that we want to clean up/deprecate the old kernel API somewhere around 2.6.36 and need user space to quit using it asap. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: soname number bump for audit-libs
On Monday 10 August 2009 12:41:48 pm Jesse Keating wrote: > > I wanted to let everyone know that I will be pushing audit-2.0 into > > rawhide in the next day or two. It will change the version number of > > libaudit. The following packages are known to have dependencies on > > audit-libs: > > I would strongly prefer that this wait until after the Alpha freeze is > over. Otherwise we'll have a huge pile of things to track and tag > should we need an updated build of anything on that list for an Alpha > blocker. Anaconda being on that list makes this a very real > possibility. OK, fine. I'll wait until after the Alpha freeze is over. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
soname number bump for audit-libs
Hello, I wanted to let everyone know that I will be pushing audit-2.0 into rawhide in the next day or two. It will change the version number of libaudit. The following packages are known to have dependencies on audit-libs: repoquery --repoid=rawhide --whatrequires --alldeps 'libaudit.so.0()(64bit)' | grep x86_64 cups-1:1.4-0.rc1.12.fc12.x86_64 xorg-x11-server-Xorg-0:1.6.99-28.20090804.fc12.x86_64 shadow-utils-2:4.1.4.1-6.fc12.x86_64 dbus-1:1.2.16-4.fc12.x86_64 cups-libs-1:1.4-0.rc1.12.fc12.x86_64 cups-lpd-1:1.4-0.rc1.12.fc12.x86_64 xorg-x11-server-Xvfb-0:1.6.99-28.20090804.fc12.x86_64 frysk-gnome-0:0.4-11.fc12.x86_64 readahead-1:1.4.9-3.fc12.x86_64 cronie-0:1.4-3.fc12.x86_64 util-linux-ng-0:2.16-3.fc12.x86_64 nscd-0:2.10.90-12.x86_64 xorg-x11-server-Xnest-0:1.6.99-28.20090804.fc12.x86_64 policycoreutils-newrole-0:2.0.68-1.fc12.x86_64 passwd-0:0.76-3.fc12.x86_64 gdm-1:2.27.4-4.fc12.x86_64 openssh-server-0:5.2p1-17.fc12.x86_64 anaconda-0:12.7-1.fc12.x86_64 sudo-0:1.7.1-5.fc12.x86_64 frysk-devel-0:0.4-11.fc12.x86_64 frysk-0:0.4-11.fc12.x86_64 xorg-x11-server-Xephyr-0:1.6.99-28.20090804.fc12.x86_64 upstart-0:0.3.11-2.fc12.x86_64 cups-php-1:1.4-0.rc1.12.fc12.x86_64 policycoreutils-0:2.0.68-1.fc12.x86_64 libxf86config-0:1.6.99-28.20090804.fc12.x86_64 ipsec-tools-0:0.7.2-3.fc12.x86_64 amtu-0:1.0.8-1.fc12.x86_64 pam-0:1.1.0-3.fc12.x86_64 aide-0:0.13.1-10.fc12.x86_64 rsh-server-0:0.17-55.fc12.x86_64 I can rebuild all these against the new audit package. If you would rather me not touch your package, just let me know. Thanks, -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: openssh-blacklist - careless waste of space.
On Friday 31 July 2009 04:42:12 am Frank Murphy wrote: > I think what is meant, it that the app is useless, without either > web\media input. Which the user should not have to do to take full > advantage of it. I think this is a bit like virus definitions. 800Mb is excessive to ship in a package. I think the definitions could be created by a script, but will take some time to generate. Maybe adding a generator for people not connected would let them recreate the content? But a 800Mb package is bigger than the livecd. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Tuesday 28 July 2009 10:22:56 am Serge E. Hallyn wrote: > > You can create an selinux context that is not allowed to exec, or only > > allowed to exec certain things. Or not allowed to connect to TCP > > sockets. Or pretty much anything else a normal user would otherwise be > > allowed to do. > > This has little to do with what Steve is trying to do. Right. All I am doing at this point is going over the daemons running as root and patching them to lower their capabilities. With libcap-ng, its generally 2-3 lines of code. As for directory perms...I'm still mulling it over. Changing perms on shadow and gshadow to should press forward, though. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Wednesday 29 July 2009 09:49:29 am Serge E. Hallyn wrote: > > There was a patch floated on selinux list circa June 2007 that would > > have allowed SELinux to directly grant capabilities. But it met a > > certain amount of resistance from people concerned about the > > implications of changing the historical position that SELinux only > > further restricts access and about how to handle states like permissive > > mode, selinux-disabled, etc seamlessly. > > > > http://marc.info/?l=selinux&m=118159187318524&w=2 > > http://marc.info/?l=selinux&m=118192327422630&w=2 > > http://marc.info/?l=selinux&m=118191791828777&w=2 > > I suppose the main problem with relying on this for granting privilege > to system processes would be that if the selinux policy wasn't loaded > for some reason, such processes (sshd, login, ...) would fail. There is also the argument that what we've been teaching people for years is that SE Linux strips away privileges and doesn't grant them. Changing the model would be somewhat confusing. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Monday 27 July 2009 09:11:33 am Serge E. Hallyn wrote: > Quoting Steve Grubb (sgr...@redhat.com): > > On Sunday 26 July 2009 08:54:26 pm Steve Grubb wrote: > > > > I trust you meant to write 0555? > > > > > > No, I really mean 005 so that root daemons are using public > > > permissions. Admins of course have DAC_OVERRIDE and can do anything. > > > Try the script in a VM and tell me if there are any problems you see. > > > > I should elaborate more. The issue is that sometimes there are secrets > > that root admins have access to that should not be available to > > semi-trusted daemons. For example, any private keys in /root or /etc. You > > do not want any daemon that could be compromised to have access to these. > > So, its safest just to set the permissions to 0005 so that they have no > > access to /root. > > But 0555 will also prevent root without CAP_DAC_OVERRIDE from writing, no? True. After some thought, I guess most secrets that a partially trusted root daemon may attempt to access would be in /root, /etc, /var, and /home. Perhaps those are the ones that need the extra tight permissions? > Using 0005 will mean root also needs CAP_DAC_OVERRIDE to read/execute, > which seems a bit much. Suddenly it needs extra privilege if i just want > it to be able to execute /bin/date. That actually seems less secure in any > real system. # ls -l /bin/date -rwxr-xr-x 1 root root 69296 2009-03-02 08:57 /bin/date The file is 0755 and therefore is executable by anyone. DAC_OVERRIDE is not needed for anything but writing to the file as in "yum update". -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Sunday 26 July 2009 09:01:14 pm Tom Lane wrote: > 0005 is certainly not meaningfully more secure than 0555. There are some secrets in files that semi-trusted root apps should not have access to. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Sunday 26 July 2009 08:54:26 pm Steve Grubb wrote: > > I trust you meant to write 0555? > > No, I really mean 005 so that root daemons are using public permissions. > Admins of course have DAC_OVERRIDE and can do anything. Try the script in a > VM and tell me if there are any problems you see. I should elaborate more. The issue is that sometimes there are secrets that root admins have access to that should not be available to semi-trusted daemons. For example, any private keys in /root or /etc. You do not want any daemon that could be compromised to have access to these. So, its safest just to set the permissions to 0005 so that they have no access to /root. I expect a few corner cases, but other than /etc/resolve.conf I don't know of any problems. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Sunday 26 July 2009 08:38:45 pm Tom Lane wrote: > Steve Grubb writes: > > The directory for /bin is 0755 root root. So, even if we drop all > > capabilities, the root acct can still trojan a system. > > > > If we change the bin directory to 005, then root cannot write to that > > directory unless it has the CAP_DAC_OVERRIDE capability. > > I trust you meant to write 0555? No, I really mean 005 so that root daemons are using public permissions. Admins of course have DAC_OVERRIDE and can do anything. Try the script in a VM and tell me if there are any problems you see. Thanks, -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Lower Process Capabilities
Hello,
I wanted to send an email to give everyone a heads up about a project I'm
working on. You can find the write-up here:
https://fedoraproject.org/wiki/Features/LowerProcessCapabilities
The basic idea goes something like this: We would like to do something to
prevent priv escalation for processes running as root. For this example, lets
take cupsd to be a good case in point. If the attacker can find a vuln with
cupsd, then they can have root privs and all that goes with it. (SE Linux may
prevent total compromise, but some people turn it off.)
What can be done is that we program the application to drop some of the
capabilities so that its not all powerful. There's just one flaw in this plan.
The directory for /bin is 0755 root root. So, even if we drop all
capabilities, the root acct can still trojan a system.
If we change the bin directory to 005, then root cannot write to that
directory unless it has the CAP_DAC_OVERRIDE capability. The idea with this
project is to not allow network facing or daemons have CAP_DAC_OVERRIDE, but
to only allow it from logins or su/sudo.
This will fundamentally change the permissions you see when doing ls -l, but
it will work as it always did for admins. If you wanted to test this out for
yourselves, you can setup a VM and run the following commands:
echo "Hardening files..."
find / -type f -perm /00700 -a -uid 0 -exec chmod u-wrx {} \; 2>/dev/null
find / -type f -perm /00070 -a -gid 0 -exec chmod g-wrx {} \; 2>/dev/null
echo "Hardening directories..."
find / -type d -perm /00200 -a -uid 0 -exec chmod u-w {} \; 2>/dev/null
find / -type d -perm /00020 -a -gid 0 -exec chmod g-w {} \; 2>/dev/null
echo "Correcting a couple things..."
find /sbin -type f -perm /0 -a -uid 0 -exec chmod u+x {} \; 2>/dev/null
find /usr/sbin -type f -perm /0 -a -uid 0 -exec chmod u+x {} \; 2>/dev/null
This project also plans to set the permissions for /etc/shadow and
/etc/gshadow to so that daemons running as root, but without DAC_OVERRIDE
cannot read the shadow file. Login, [gkx]dm, and sshd will still have
DAC_OVERRIDE or this wouldn't work.
Does a system running like this still work? Yes it does. But there is still
one rough spot. That is the /etc/resolve.conf file. The problem is that if we
follow the new theory of only allowing system updates with DAC_OVERRIDE, then
root daemons cannot update dynamically created files. The solution to this is
to move those into a directory owned by an account other than root and have
the daemon running under that account to write the file.
This would mean that anything that writes to /etc/resolve.conf, would need to
run under this new acct. And /etc/resolve.conf would need to be moved to
something like /etc/resolve/resolve.conf. And then that is symlinked back to
/etc/resolve.conf for the transition.
The last phase of the project is to play whack-a-mole and fix permission
problems in packages that specify file permissions explicitly. The plan is to
cover @core files first as I would like to make the minimal install work first
and then branch out to other use cases.
Asbestos underwear is firmly in place. Let me know if any one has concerns.
Also please try out the script above on a VM before posting so that you can
assure yourself that everything still works. :)
Thanks,
-Steve
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On Friday 24 July 2009 04:56:51 pm Casey Dahlin wrote: > > Just because selinux has policy doesn't mean the app is installed. > > If the app is not installed nothing is running in its context, so none of > the rules will ever trigger. If the attacker can work out the chain of allowed transitions, they can enter that context. > >> The simplest mechanism I can see for doing that is to allow SELinux > >> context to be referenced in the firewall rules. This prevents either > >> system from having to be grotesquely modified. > >> > >> An example rule might look like this: > >> > >> -A INPUT -Z apache_t -j ACCEPT > >> > >> Here we tell the firewall to allow incoming traffic that will be > >> intercepted in userspace by a process in the apache_t context. > > > > I don't like this. Its not tying to any port. For example, suppose there > > is a vulnerability in cups and apache is not running, the cups app could > > start listening on other ports and the rule would allow connections. > > Only if cups were running in the apache_t context. I don't think I explained it well. I was thinking what if you had this rule: -A INPUT -Z cups_t -j ACCEPT and then cups was compromised and started listening on port 80. Since the above rule has no port restrictions and cups is allowed to accept connections, would cups now be able to start serving web pages? -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: RFE: FireKit
On Thursday 23 July 2009 02:16:10 pm Ahmed Kamal wrote: > Here's a RFE for FireKit, a firewall desktop "kit". What this does is: > 1- Exposes a dbus interface for applications to programatically open/close > ports I don't exactly like this. If one application gets compromised, it can now open other ports that may be protected. Previously, it would require CAP_NET_ADMIN or some other root possessed capability to make changes. There are a lot of important services above 1024 that a normal user could bind to. You don't want the system to suddenly open those ports and allow traffic. > 2- Monitors as new daemons/applications that listen on non lo interfaces > are started, checks if iptables is currently blocking them, and if so, > warns the user that application X is currently blocked by the firewall This part I like. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Firewall rules using SELinux context (Was Re: RFE: FireKit)
On Friday 24 July 2009 03:47:51 pm Casey Dahlin wrote: > A couple of mentions of SELinux have cropped up in the FireKit thread, > which got me thinking about the Firewall and SELinux and ways in which they > are similar. I had the following thought: > > SELinux already has a lot of policy information from which we might like to > determine whether ports should be open to a particular program. Just because selinux has policy doesn't mean the app is installed. > The simplest mechanism I can see for doing that is to allow SELinux context > to be referenced in the firewall rules. This prevents either system from > having to be grotesquely modified. > > An example rule might look like this: > > -A INPUT -Z apache_t -j ACCEPT > > Here we tell the firewall to allow incoming traffic that will be > intercepted in userspace by a process in the apache_t context. I don't like this. Its not tying to any port. For example, suppose there is a vulnerability in cups and apache is not running, the cups app could start listening on other ports and the rule would allow connections. > This does break in at least one way from traditional SELinux policy: > something external to SELinux is interpreting the meaning of the context. The kernel should always decide. Since this is a security mechanism that would be part of our Common Criteria work it would have to play by the rules. If its doing security enforcement, it will need to log AVCs. I would recommend leaving IPTables as is. Its working great at what its designed to do. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: prelink: is it worth it?
On Thursday 09 July 2009 10:45:55 am devzero2000 wrote: > There are also other two big problem, imho, now, with prelink support: > > 1 - it render impossibile to do a centralizzated integrity checker (with as > example rfc.sf.net ): very very bad The aide program in rawhide is prelink friendly. So there are integrity checkers that can be used. As for security, prelink stirring around address space randomization is good for security. For example, this hack needed prelink not to have run to get the exploit reliable: http://invisiblethingslab.com/pub/xenfb-adventures-10.pdf There are more examples like this. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: unable to include capability.h
On Friday 12 June 2009 09:02:39 am Daniel Lezcano wrote: > As I only need the CAP_SYS_BOOT, I will define it manually in the source > code and will remove the include, that's ugly but anyway... :/ Alternatelyas of today, libcap-ng is now in Fedora. It has a far simpler API and you should be able to do things in 2-3 lines of code. For example, if you wanted to use it to retain only CAP_SYS_BOOT, the code would be: capng_clear(CAPNG_SELECT_BOTH); capng_update(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED, CAP_SYS_BOOT); capng_apply(CAPNG_SELECT_CAPS); You're done. If you know you application has no children, then you would want to change the last line to use CAPNG_SELECT_BOTH so that the bounding set is cleared. libcap-ng has 1 relocation and libcap has 35, so it starts up faster. Its also smaller in size and has better analysis tools. More info can be found here: http://people.redhat.com/sgrubb/libcap-ng/ I'll be setting up a Fedora 12 project in the next few days to drop privs everywhere. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wednesday 03 June 2009 04:57:32 pm Kevin Kofler wrote: > Steve Grubb wrote: > > And then should the bug be closed hoping that one day you pull in a > > package that solves the user's problem? > > If the bug is fixed upstream, the Fedora report can be reopened with a > request to backport the fix (but that should only be done if it's important > enough that it cannot wait for the next bugfix update getting pushed > anyway). When bugs are closed, they disappear from the reporter's bz frontpage. Its far easier to leave the bug open and close it when the fixed package gets pushed through bodi. > Until then, why do we need to have the bug open in 2 places? Yes. Many times when I am evaluating a package I look in bz to see what bugs are open against it as a test sniff of what its quality might be like. If the maintainer is closing everything as upstream bugs, I might be installing a steaming hot pile of awful and not knowing its got lots of problems. Also by closing unresolved bugs you are inviting duplicate bug reports. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Tuesday 02 June 2009 06:17:02 pm Steven M. Parrish wrote: > This is from the official Bugzappers page > https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#Upstreamin So, this raises the question about bugzappers. Should they be making the determination for maintainers that the reporter should have taken the issue upstream? Do bug zappers take into consideration the severity of the bug before pushing someone upstream? > The bug is not a packaging bug, the package maintainer has no plans to work > on this in the near future, and there is an upstream bug tracking system > other than the Red Hat Bugzilla. Is there communication between maintainer and bugzapper before doing this? > Maintainers should be free to either fix it locally (time permitting) and > upstream the patch or request that the bug be filed at the upstream > projects tracker for the upstream developers to resolve it. > > If it is sent upstream the bug is closed as UPSTREAM and our local report > is cross-referenced to the upstream one. That way the maintainer and all > interested parties can follow its progress. Not if its closed. How would I be notified that the fix is in Fedora? If the bug is severe enough, shouldn't the upstream commit be applied to Fedora's package and the package pushed out for testing? Is all this going to happen if the bug is closed? -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Tuesday 02 June 2009 11:09:49 pm Ralf Corsepius wrote: > Kevin Kofler wrote: > > Steve Grubb wrote: > >> I don't want to start a long thread, but just to ask a couple questions > >> for my own clarification. Does a maintainer's responsibilities end with > >> packaging bugs? IOW, if there is a problem in the package that is > >> _broken code_ do they need to do something about it or is it acceptable > >> for them to close the bug and say talk to upstream? > > > > It's the reporter's job to report the bug upstream when asked to do so. > > I disagree. Reporters are "users" - "customers" if you like to. > > You can't expect them to do anything, nor demand them to do anything, > nor force them to do anything. > > That said, I consider it to be a Fedora package's maintainer's job and > duty to act as moderator/arbiter/coordinator to initiate appropriate > communication/interaction between all different parties (reporter, > packager, upstreams) "when necessary/if required". For the record, I agree with this sentiment. If there's a bug in my packages, I want to fix it and not cause the reporter to have to get upstream bz accounts or join upstream mail lists just because they reported a problem. I will interact with the reporter until I see the problem myself. And then I can fix it or show upstream the problem. Thanks everybody for the opinions. I just wanted to raise awareness on this topic. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Tuesday 02 June 2009 07:34:17 pm Kevin Kofler wrote: > Steve Grubb wrote: > > I don't want to start a long thread, but just to ask a couple questions > > for my own clarification. Does a maintainer's responsibilities end with > > packaging bugs? IOW, if there is a problem in the package that is _broken > > code_ do they need to do something about it or is it acceptable for them > > to close the bug and say talk to upstream? > > It's the reporter's job to report the bug upstream when asked to do so. And then should the bug be closed hoping that one day you pull in a package that solves the user's problem? > Fixing bugs often requires two-way communication, so it's important for > upstream to have a real reporter to talk to, I don't see why it should be > the maintainer's job to play the relaying monkey. Its real simple. In reporting the bug, people are asked how to reproduce the bug. If its reproducible by the maintainer, the user is no longer required to solve the problem and all you need to do is ask them to do a retest. If the bug is not reproducible, then things do get a little trickier. I would still take the bug report to upstream and see if it rings any bells, but I would not close the bug. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Maintainer Responsibilities
Hello, I don't want to start a long thread, but just to ask a couple questions for my own clarification. Does a maintainer's responsibilities end with packaging bugs? IOW, if there is a problem in the package that is _broken code_ do they need to do something about it or is it acceptable for them to close the bug and say talk to upstream? Do we want those bugs open to track when the bug is fixed in the distro? I'll accept whatever the answer is, I'm just curious. Thanks, -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
