Bug 52725 - parent directories are infected with 'net shared' flag
Summary: parent directories are infected with 'net shared' flag
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: rpm   
(Show other bugs)
Version: 1.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: David Lawrence
: 52729 90941 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-28 14:25 UTC by Enrico Scholz
Modified: 2007-04-18 16:36 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-12 20:15:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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):


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

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

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

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 ...


Comment 7 Enrico Scholz 2003-05-16 21:32:19 UTC

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.

Note You need to log in before you can comment on or make changes to this bug.