Bug 50743 - nfsutils source rpm requires user intervention during install
Summary: nfsutils source rpm requires user intervention during install
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils   
(Show other bugs)
Version: 7.1
Hardware: All Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-02 19:12 UTC by Rick Moseley
Modified: 2007-04-18 16:35 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-04-06 03:11:20 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 Rick Moseley 2001-08-02 19:12:04 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2smp i686)

Description of problem:
A bug was introduced to the nfsutils spec file when a delete of rpc.quotad
was added.  It turns out /sbin/rpc.quotad does not have write privileges
and when the "rm" command is used to delete it, the user is asked if they
want to indeed delete the "write-protected" file.  This is not a problem
when doing the "rpm -bi" from a command line, but when the "rpm -bi" is
issued from a shell script the install halts right at the "rm" command for
rpc.quotad.  Since no terminal is associated, the user never sees the
question and it appears the install has hung.  This command is in the spec
file and should be changed to "rm -f" so no user intervention is needed.

How reproducible:

Steps to Reproduce:
1.run the command "rpm -bi nfs-utils-0.3.1-5.src.rpm"
2.wait for the script to ask the user whether they want to delete
rpc.quoated or not

Additional info:

Comment 1 Bob Matthews 2001-08-06 15:33:02 UTC
/usr/sbin/rpc.rquotad should have 755 perms.  If the sysadmin changed the
permissions on rpc.rquotad to 555, rpm shouldn't override this.

Comment 2 Rick Moseley 2001-08-06 16:29:31 UTC
I am building the SRPM with a script that changes "buildroot" and inside the
/home/rmoseley/ELProduct/buildtree/nfsutils/usr/sbin directory the permissions
for rpc.quotad are "555" as they come out of the build part of the SRPM.  Nobody
has changed the permissions.  I do not know why the permissions are set to 555
after the build process, that is out of my control.  All I know is that coming
out of the "build" part of the nfs-utils SRPM and before getting to the
"install" part of the SRPM the permissions are set to 555 by whoever did the
"makefile".  When rpc.quotad is attempted to be deleted you get prompted about
deleting a write protected file.  We'll handle patching it here in Huntsville
before we distribute it in our Embedded Linux box product if you don't think
that is a bug.

Comment 3 Bob Matthews 2001-08-06 18:49:55 UTC
It's definitely a bug if rquotad gets installed in the build root with 555

The problem is, I can't reproduce it here.  When I perform the build, rpm
installs rpc.rquotad with perms 755.  Running rpm -bi -vv generates the
following line:

> install -m 755 -s rquotad /var/tmp/nfs-utils/root-usr/sbin/rpc.rquotad

Perhaps the umask in the shell is too restrictive?

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