Bug 49636 – rpc.statd is on by default, even if unused

Bug 49636 - rpc.statd is on by default, even if unused

Summary:	rpc.statd is on by default, even if unused

Status:	CLOSED NOTABUG

Aliases:	None

Product:	Red Hat Linux
Classification:	Retired
Component:	nfs-utils (Show other bugs)
Sub Component:
Version:	7.3
Hardware:	i386 Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Stephen Tweedie
QA Contact:	Brian Brock
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2001-07-22 09:40 EDT by Steve Bonneville
Modified:	2007-04-18 12:35 EDT (History)
CC List:	0 users

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2002-10-11 02:40:13 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Steve Bonneville 2001-07-22 09:40:32 EDT

Description of Problem:  Now that the portmap service is on by default (due
to the
addition of sgi_fam), rpc.statd is on again by default (the nfslock service
ships
chkconfig-ed on, even though nfs ships chkconfig-ed off).  In 7.1, while we
ship
'chkconfig nfslock on', since portmap is off the nfslocking services are
off.

rpc.statd has been a source of remote-user security vulnerabilities in the
past, and
probably should not be turned on if it is not in use.

We should set 'chkconfig nfslock off' by default unless there's an
overriding reason 
not to do so.

Comment 1 Pete Zaitcev 2002-10-11 02:40:06 EDT

Let the master to NOTABUG it :)
/me washes hands

Comment 2 Stephen Tweedie 2002-10-11 07:17:33 EDT

There are reasons for needing rpc.statd to run at boot.  If you do a manual
"service nfs on" for any reason, then crash while holding NFS locks, you'll end
up never releasing that lock on the server, ever, unless you run rpc.statd on
the subsequent reboot.  It's rpc.statd which informs the server that the client
reboot has happened and that lock cleanup must occur.

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