Bug 52725

Summary: parent directories are infected with 'net shared' flag
Product: [Retired] Red Hat Raw Hide Reporter: Enrico Scholz <rh-bugzilla>
Component: rpmAssignee: Paul Nasrat <nobody+pnasrat>
Status: CLOSED UPSTREAM QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-12 20:15:22 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Enrico Scholz 2001-08-28 14:25:26 UTC
Description of Problem:

When using the '%_netsharedpath' macro, all parent-directories of files
being in this path are marked as 'net shared' also.

Example below uses '/usr/share/man' as _netsharedpath but /usr und
/usr/share will be marked also.

This is critical because cpio can fail under some circumstances (e.g. try
'/usr/share/man/man1' as _netsharedpath).


Version-Release number of selected component (if applicable):

rpm-4.0.3-0.96


Steps to Reproduce:
1. p=/var/tmp/rpm-netshared-test
2. alias RPM="rpm --root $p --eval %define\ _netsharedpath\ /usr/share/man"
3. mkdir -p $p/var/lib/rpm
4. RPM --initdb
5. RPM -U setup-2.5.4-1.noarch.rpm filesystem-2.1.5-2.noarch.rpm
6. RPM -qas | grep 'net shared'


Actual Results:

(6) outputs:
net shared    /usr
net shared    /usr/share
net shared    /usr/share/man
...

Expected Results:

(6) outputs
net shared /usr/share/man
...

Comment 1 Enrico Scholz 2001-08-28 14:26:44 UTC
Forgot to mention: the setup and filesystem package are from the roswell2-beta.

Comment 2 Jeff Johnson 2001-08-28 14:51:07 UTC
*** Bug 52729 has been marked as a duplicate of this bug. ***

Comment 3 Enrico Scholz 2003-05-15 18:05:37 UTC
*** Bug 90941 has been marked as a duplicate of this bug. ***

Comment 4 Jeff Johnson 2003-05-15 18:23:19 UTC
I believe we're saying the same thing but have different
vocabularies.

Yes, rpm needs to be made smarter about rdonly and NFS paths.
What's naive and primitive is that the policy decision of
the current %_netsharedpath implementation is
   Don't install any file on this path.

Yes, more sophisticated policies, like using the (now available)
file class information are needed, but (at least in my vocabulary)
that's brand new stuff, not the current dumbsh*t %_netsharedpath
implementation.

Are we in agreement? If so, what I'm look for is additional ideas
about what policies rpm CLI users find useful because, without
consensus on what should be done, I cannot proceed.

(BTW, there's also an RFE for netsharedpath replacement someplace
in my pile of rpm bugs, I'll probably dupe this bug there for everyone's
sanity.)

Comment 5 Enrico Scholz 2003-05-15 18:45:22 UTC
I can not fully agree with the second paragraph. I am using _netsharedpath in
the following situations:

* NFS mounts
* read-only mounts (related with NFS)
* directories mounted like 'mount --bind /foo /bar'
* top-level directories of automounters
* normal directories which are handled by other mechanisms (cfengine)

For these situations, %_netsharedpath and its 'do not install any file there'
policy is ideally; perhaps I would add the sentence '... but assume the files
are already there' to it.

Replacing %_netsharedpath with 'any readonly or NFS mountpoint' would not be enough.


Fileclass information can help on some _netsharedpath anomalies but it is an
independent technology.

Comment 6 Jeff Johnson 2003-05-16 13:59:04 UTC
OK, then we agree. I'm not suggesting %_netsharedpath removal,
only replacement with a more sophisticated set of policies.

What stops me from adding Yet More Arcane side effects during install
is that these policies can seem very mysterious and surprising, just
like %config handling is, to the average user, so I need to start
educating rpm users and warn them before just slamming in Yet More Arcane Stuff.

Since I know (and have 3-4 bug reports to prove it ;-) you want better
policies, would you mind writing up something and dropping an RFE on
rpm-list and testers-list? Implementations are easy, consensus is hard ...

Thanks.

Comment 7 Enrico Scholz 2003-05-16 21:32:19 UTC
https://www.redhat.com/mailman/private/rpm-list/2003-May/msg00301.html

But the misclassification of /usr described by this bug can not be solved by
policies. ;)

Comment 8 Enrico Scholz 2004-06-02 00:28:11 UTC
still with rpm-4.3.1-0.3


Comment 9 Jeff Johnson 2006-02-12 19:38:09 UTC
FWIW, this is only true for setup+filesystem into a chroot. This command gives expected results
    rpm -Uvh --define '_netsharedpath /usr/share/info' time-1.7-27.i386.rpm

Comment 10 Jeff Johnson 2006-02-12 20:15:22 UTC
And here's the bleeping patch. Happy now?
Index: lib/transaction.c
===============================================================
====
RCS file: /cvs/devel/rpm/lib/transaction.c,v
retrieving revision 1.315.2.24
diff -u -b -B -w -p -r1.315.2.24 transaction.c
--- lib/transaction.c   5 Jan 2006 20:11:50 -0000       1.315.2.24
+++ lib/transaction.c   12 Feb 2006 20:17:16 -0000
@@ -775,6 +775,9 @@ static void skipFiles(const rpmts ts, rp
                    /*@innercontinue@*/ continue;
                if (strncmp(dn, *nsp, dnlen))
                    /*@innercontinue@*/ continue;
+               /* Insure that only the netsharedpath basename is compared. */
+               if ((s = strchr((*nsp) + dnlen, '/')) != NULL && s[1] != '\0')
+                   /*@innercontinue@*/ continue;
                if (strncmp(bn, (*nsp) + dnlen, bnlen))
                    /*@innercontinue@*/ continue;
                len = dnlen + bnlen;

Seriously, you're the only person I know of messing around with setup+filesystem in chroot's using
%_netsharedpath, and your programming skills could have found the problem in less
time than you've whined about "rpm bugs" over the last several years.

Fixed in rpm cvs, should be in rpm-4.4.5-0.10 when built.

Comment 11 Enrico Scholz 2006-02-12 21:11:36 UTC
@comment #9:

What means "only"? When you can not bootstrap a system because 'cpio' fails due
to this misclassification, this is more than "only".

The 'chroot' part is not true either; it happens on real system setups too (it's
not trivial to inject rpm macros into anaconda, but it is possible).


This bug affects not only setup+filesystems it causes the same failures with

| %_install_langs C


@comment #10:

I am not sure about the history of this bug (4.5 years are too much for me to
remember all details). But I am pretty sure that the chroot in the initial
comment was used only to give you a reproducer and the problem occured in a (for
you: some more) real-world situation. At this time, it was probably not critical
enough for me to develop a bug-fix resp. the work-arounds were much easier.

At some stage (2004/2005) the bug become critical but the workarounds were still
easy and I had to support older rpm version which would not have a potential
bugfix. So there was no reason for me to develop a patch (especially because
trivial things like '-p' flags in 'gendiff' were ignored).

Completely unrelated statements like "The %_netsharedpath mechanism is known
feeble and deficient" or your comments <#9 in this bug are things which let me
"whine about rpm bugs". An unhelpful pragmatism (e.g. bug #173285#3 translates
to "I know, the current rpmdb functionality in chroot is shit, but I won't fix
it" for me) is doing its part to make me upset about rpm.


Nevertheless, much thanks for the fix; we will see when it will appear in FC.