Hi,
I've ran into a real problem where package A requires B, and B requires A : The current httpd and httpd-suexec packages from FC Development. I've just installed FC Test from the latest ISOs, a minimal system, then did "yum install httpd" from there. The problem is that during the transaction, httpd-suexec (which got pulled in as a dependency) got installed first, outputting the message "apache group doesn't exist, using root"... BAD! Yes, the suexec binary is now sgid root on that system instead of sgid apache.
Now... I'm posting here before bugzilla'ing this since I'd like to know what the general opinion is regarding packages requiring some of their own sub-packages like this. I really think it should be avoided since there are some side-effects like this one that can arise. Furthermore, I don't get why httpd-suexec nor php-mbstring (as another example) got split off... the main purpose I can see for such cases is for the original package to be overridden by another one providing the same functionality, like the X Mesa libraries.
Matthias
On Tue, 7 Sep 2004, Matthias Saou wrote:
Furthermore, I don't get why httpd-suexec nor php-mbstring (as another example) got split off... the
IMO, In the case of httpd-suexec, httpd should *NOT* require it, and the point of installing the subpkg would be to enable/disable the suexec functionality.
-- Rex
On Tuesday 07 September 2004 18:08, Rex Dieter wrote:
On Tue, 7 Sep 2004, Matthias Saou wrote:
Furthermore, I don't get why httpd-suexec nor php-mbstring (as another example) got split off... the
IMO, In the case of httpd-suexec, httpd should *NOT* require it, and the point of installing the subpkg would be to enable/disable the suexec functionality.
Which was a real enhancement, manually removing suexec after every update is really annoying (especially if your forgot about it and looking for the cause of errors...) If there really is a dep in httpd on httpd-suexec this is IMHO a bug. (I assume it was introduced for the upgrade from old httpd with integrated suexec to the new one with suexec subpackage)
On Tue, 2004-09-07 at 16:39, Matthias Saou wrote:
Now... I'm posting here before bugzilla'ing this since I'd like to know what the general opinion is regarding packages requiring some of their own sub-packages like this. I really think it should be avoided since there are some side-effects like this one that can arise.
Agreed. But in case a dependency "loop" like this between some packages is not avoidable (in general, not in this particular case) and the order in which they are installed inside one transaction matters, one of them should use "PreReq" and the other "Requires" in order to break the loop in predictable fashion (== PreReq "wins"; the package containing it will be installed last). That's what I've heard the difference between PreReq and Requires is, anyway.
Ville Skyttä wrote:
Agreed. But in case a dependency "loop" like this between some packages is not avoidable
In many cases where foo Requires foo-bar and foo-bar Requires foo, IMO, there shouldn't *be* a foo-bar subpackage at all. One example off the top of my head: openoffice.org openoffice.org-libs What's the point of the separate -libs subpkg?
-- Rex
On Tue, 07 Sep 2004 15:15:30 -0500 Rex Dieter rdieter@math.unl.edu wrote:
Ville Skyttä wrote:
Agreed. But in case a dependency "loop" like this between some packages is not avoidable
In many cases where foo Requires foo-bar and foo-bar Requires foo, IMO, there shouldn't *be* a foo-bar subpackage at all. One example off the top of my head: openoffice.org openoffice.org-libs What's the point of the separate -libs subpkg?
I agree. Another example that I was thinking about: rpm and popt. They *are* both built from the same SRPM (rpm). rpm is always in the system, and it requires popt in the exact version. Why not build *single* rpm containing them both???
Jarek
Ville Skyttä wrote:
On Tue, 2004-09-07 at 16:39, Matthias Saou wrote:
Now... I'm posting here before bugzilla'ing this since I'd like to know what the general opinion is regarding packages requiring some of their own sub-packages like this. I really think it should be avoided since there are some side-effects like this one that can arise.
Agreed. But in case a dependency "loop" like this between some packages is not avoidable (in general, not in this particular case) and the order in which they are installed inside one transaction matters, one of them should use "PreReq" and the other "Requires" in order to break the loop in predictable fashion (== PreReq "wins"; the package containing it will be installed last). That's what I've heard the difference between PreReq and Requires is, anyway.
Eh? jbj has confirmed on multiple occasions that there is NO DIFFERENCE between PreReq and Requires.
Warren Togami wtogami@redhat.com
On Tue, 07 Sep 2004 10:27:37 -1000, Warren Togami wrote:
Ville Skyttä wrote:
On Tue, 2004-09-07 at 16:39, Matthias Saou wrote:
Now... I'm posting here before bugzilla'ing this since I'd like to know what the general opinion is regarding packages requiring some of their own sub-packages like this. I really think it should be avoided since there are some side-effects like this one that can arise.
Agreed. But in case a dependency "loop" like this between some packages is not avoidable (in general, not in this particular case) and the order in which they are installed inside one transaction matters, one of them should use "PreReq" and the other "Requires" in order to break the loop in predictable fashion (== PreReq "wins"; the package containing it will be installed last). That's what I've heard the difference between PreReq and Requires is, anyway.
Eh? jbj has confirmed on multiple occasions that there is NO DIFFERENCE between PreReq and Requires.
Sure about that? BuildPreReq and BuildRequires are equal. But quoting RPM documentation:
\subsection dependencies_prereqs Prereqs
Prereqs are different from requires only in that a PreReq is guaranteed to be installed before the package that contains the PreReq. PreReq's are used only to order packages, otherwise PreReq's are exactly the same as a Requires: dependency.
Michael Schwendt wrote:
On Tue, 07 Sep 2004 10:27:37 -1000, Warren Togami wrote:
Eh? jbj has confirmed on multiple occasions that there is NO DIFFERENCE between PreReq and Requires.
Prereqs are different from requires only in that a PreReq is guaranteed to be installed before the package that contains the PreReq. PreReq's are used only to order packages, otherwise PreReq's are exactly the same as a Requires: dependency.
Yep. In my experience, at least for FC2 (and most earlier releases) that both Prereq and Requires(post) *does* make the Prereq'd item get installed first.
-- Rex
Rex Dieter wrote:
Prereqs are different from requires only in that a PreReq is guaranteed to be installed before the package that contains the PreReq. PreReq's are used only to order packages, otherwise PreReq's are exactly the same as a Requires: dependency.
Yep. In my experience, at least for FC2 (and most earlier releases) that both Prereq and Requires(post) *does* make the Prereq'd item get installed first.
<warren> jbj, is PreReq exactly equivalent to Requires? <jbj> warren: except for loop snipping (loops are different problem) yes, identical. <jbj> when loops are snipped, PreReq is honored, but all Requires: in loop are ignored. <jbj> again, loops need to be solved in other ways.
Looks like I need to go back through all the specs I edited in the past year and see if I need to revert any PreReq to Requires changes...
Warren
Warren Togami wrote:
<warren> jbj, is PreReq exactly equivalent to Requires? <jbj> warren: except for loop snipping (loops are different problem) yes, identical. <jbj> when loops are snipped, PreReq is honored, but all Requires: in loop are ignored. <jbj> again, loops need to be solved in other ways.
Looks like I need to go back through all the specs I edited in the past year and see if I need to revert any PreReq to Requires changes...
<jbj> warren: they *are* exactly equivalent, loops is a different problem, you can't possibly fix. <jbj> you can't possibly fix by choosing PreReq: or Requires: <warren> jbj, *confused*
Warren
On Tue, 2004-09-07 at 11:55 -1000, Warren Togami wrote:
<jbj> warren: they *are* exactly equivalent, loops is a different problem, you can't possibly fix. <jbj> you can't possibly fix by choosing PreReq: or Requires: <warren> jbj, *confused*
You can't fix but you can be graceful about it :)
Rui
On Tue, 2004-09-07 at 23:27, Warren Togami wrote:
Eh? jbj has confirmed on multiple occasions that there is NO DIFFERENCE between PreReq and Requires.
Well, it has been said by him and others so many times, so many different ways, in so many contexts, with so many "affected" rpm versions that it is not really clear to me (and I bet I'm not the only one), no need to shout. Even jbj's "confirmations" have been sort of self-contradicting.
One such example is [1], where the first non-quoted paragraph from jbj mentions "preserving the PreReq: guarantee" for resolving circular dependencies with recent versions of rpm, and the last one says PreReq is "not any more" used for that for the same versions of rpm AFAICT.
Whatever it's called nowadays, I don't care; The point made is still valid though: if loops cannot be avoided and the order matters, they should be made predictable with whatever tools are available, if any.
If PreReq does not "exist" in the sense it used to any more, one such "tool" which supposedly nowadays at least partially replaces/provides that functionality are "context markers" (ie. Requires(pre) and friends if I've understood _that_ correctly).
[1] https://lists.dulug.duke.edu/pipermail/rpm-metadata/2003-October/000095.html
On Wed, Sep 08, 2004 at 12:24:21AM +0300, Ville Skyttä wrote:
If PreReq does not "exist" in the sense it used to any more, one such "tool" which supposedly nowadays at least partially replaces/provides that functionality are "context markers" (ie. Requires(pre) and friends if I've understood _that_ correctly).
[1] https://lists.dulug.duke.edu/pipermail/rpm-metadata/2003-October/000095.html
I thought Requires(pre) and friends are just for dependencies of the scripts?
Can anyone state definitively (and preferably in plain English), if I have in the httpd-suexec subpackage:
PreReq: httpd
the files contained in said package will be installed only after the %pre script of the httpd package has run?
joe
On Wed, 2004-09-08 at 10:07, Joe Orton wrote:
On Wed, Sep 08, 2004 at 12:24:21AM +0300, Ville Skyttä wrote:
If PreReq does not "exist" in the sense it used to any more, one such "tool" which supposedly nowadays at least partially replaces/provides that functionality are "context markers" (ie. Requires(pre) and friends if I've understood _that_ correctly).
[1] https://lists.dulug.duke.edu/pipermail/rpm-metadata/2003-October/000095.html
I thought Requires(pre) and friends are just for dependencies of the scripts?
Hmm, I think, you're mixing this up with BuildPreRequires and BuildRequires.
Can anyone state definitively (and preferably in plain English), if I have in the httpd-suexec subpackage:
PreReq: httpd
the files contained in said package will be installed only after the %pre script of the httpd package has run?
Basically, "PreReq: httpd" denotes that "httpd" must be installed when the package is installed.
At least some versions of rpm (e.g. the version shipped with FC2) re-sort package installation order if being given several packages:
Example: 2 packages, gaga and gaga-addon, with gaga-addon using PreReq: gaga
# rpm -Uv gaga-0-0.fdr.x.i386.rpm gaga-addon-0-0.fdr.x.i386.rpm Preparing packages for installation... gaga-0-0.fdr.x gaga-addon-0-0.fdr.x # rpm -e gaga gaga-addon
# rpm -Uv gaga-addon-0-0.fdr.x.i386.rpm gaga-0-0.fdr.x.i386.rpm Preparing packages for installation... gaga-0-0.fdr.x gaga-addon-0-0.fdr.x
[Note: rpm modified installation order]
If installers (up2date/yum/apt) behave differently (I haven't checked), they'd have to be considered broken :-)
Ralf
On Wed, Sep 08, 2004 at 09:07:07AM +0100, Joe Orton wrote:
On Wed, Sep 08, 2004 at 12:24:21AM +0300, Ville Skyttä wrote:
If PreReq does not "exist" in the sense it used to any more, one such "tool" which supposedly nowadays at least partially replaces/provides that functionality are "context markers" (ie. Requires(pre) and friends if I've understood _that_ correctly).
[1] https://lists.dulug.duke.edu/pipermail/rpm-metadata/2003-October/000095.html
I thought Requires(pre) and friends are just for dependencies of the scripts?
Yes, you usually want to ensure that script interpreteres are installed prior to scriptel runtime :)
Can anyone state definitively (and preferably in plain English), if I have in the httpd-suexec subpackage:
PreReq: httpd
the files contained in said package will be installed only after the %pre script of the httpd package has run?
That's the idea, you could test with
rpm -ihv httpd httpd-suexec
vs
rpm -ihv httpd-suexec httpd
Output should be in both cases the same (first httpd then httpd-suexec), if you employ the above change.
On Wed, 8 Sep 2004 09:07:07 +0100, Joe Orton wrote:
On Wed, Sep 08, 2004 at 12:24:21AM +0300, Ville Skyttä wrote:
If PreReq does not "exist" in the sense it used to any more, one such "tool" which supposedly nowadays at least partially replaces/provides that functionality are "context markers" (ie. Requires(pre) and friends if I've understood _that_ correctly).
[1] https://lists.dulug.duke.edu/pipermail/rpm-metadata/2003-October/000095.html
I thought Requires(pre) and friends are just for dependencies of the scripts?
Yes, but since the scriptlets are contained within the same package, Requires(pre) is the earliest you can get for specifying pre-install dependencies of the entire package.
Can anyone state definitively (and preferably in plain English), if I have in the httpd-suexec subpackage:
PreReq: httpd
the files contained in said package will be installed only after the %pre script of the httpd package has run?
Whatever package contains above line will be installed after httpd has been installed. httpd becomes a pre-install requirement.
The problem is that during the transaction, httpd-suexec (which got pulled in as a dependency) got installed first, outputting the message "apache group doesn't exist, using root"... BAD!
Really bad. I would think this bug needs fast attention. If you download a package from a 3rd party that has buffer overflows and is setgid, you now have a buggy program with buffer overflows running as root. Any setgid installation that fails should never revert to root, it should fail immediately and let the admin take care of it.
Was this filed in bugzilla?
-Steve Grubb
__________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail
On Tue, Sep 07, 2004 at 01:57:37PM -0700, Steve G wrote:
The problem is that during the transaction, httpd-suexec (which got pulled in as a dependency) got installed first, outputting the message "apache group doesn't exist, using root"... BAD!
Really bad. I would think this bug needs fast attention. If you download a package from a 3rd party that has buffer overflows and is setgid, you now have a buggy program with buffer overflows running as root. Any setgid installation that fails should never revert to root, it should fail immediately and let the admin take care of it.
Not sure about that - it should certainly not set the setuid bit, but its probably easier for the admin if it still installs it.
Was this filed in bugzilla?
Ditto Q: and bug id ?
If you download a package from a 3rd party that has buffer overflows and is setgid, you now have a buggy program with buffer overflows running as root.
Not sure about that - it should certainly not set the setuid bit
You don't need the setuid bit of root to start with. The setgid bit of root is just enough wiggle room on most systems to compromise the whole thing in a few steps.
-Steve Grubb
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Alan Cox wrote :
[...]
Was this filed in bugzilla?
Ditto Q: and bug id ?
#132045 "httpd and httpd-suexec dependency reciprocity" : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132045
Matthias
On Tue, Sep 07, 2004 at 03:39:47PM +0200, Matthias Saou wrote:
I've ran into a real problem where package A requires B, and B requires A : The current httpd and httpd-suexec packages from FC Development. I've just installed FC Test from the latest ISOs, a minimal system, then did "yum install httpd" from there. The problem is that during the transaction, httpd-suexec (which got pulled in as a dependency) got installed first, outputting the message "apache group doesn't exist, using root"... BAD! Yes, the suexec binary is now sgid root on that system instead of sgid apache.
Ouch :(
Now... I'm posting here before bugzilla'ing this since I'd like to know what the general opinion is regarding packages requiring some of their own sub-packages like this. I really think it should be avoided since there are some side-effects like this one that can arise. Furthermore, I don't get why httpd-suexec nor php-mbstring (as another example) got split off... the main purpose I can see for such cases is for the original package to be overridden by another one providing the same functionality, like the X Mesa libraries.
php-mbstring is not required by php in FC3, it's required in the FC2 update to avoid silently removing functionality during the update or a later upgrade to FC3.
joe
Joe Orton wrote :
[...]
php-mbstring is not required by php in FC3, it's required in the FC2 update to avoid silently removing functionality during the update or a later upgrade to FC3.
Thanks for clarifying this one, it makes sense ;-)
Matthias