Slackware This Forum is for the discussion of Slackware Linux.
|
| Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
 |
GNU/Linux Basic Guide
This 255-page guide will provide you with the keys to understand the philosophy of free software, teach you how to use and handle it, and give you the tools required to move easily in the world of GNU/Linux. Many users and administrators will be taking their first steps with this GNU/Linux Basic guide and it will show you how to approach and solve the problems you encounter.
Click Here to receive this Complete Guide absolutely free. |
|
 |
03-18-2012, 01:33 AM
|
#1
|
|
LQ 5k Club
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Debian Squeeze (server), Slackware 13.37 (netbook), Slackware64 14.0 (desktop),
Posts: 8,367
|
rpc.statd: Running as root. chown /var/lib/nfs to choose different user
What is "good practice" for the ownership of /var/lib/nfs?
On a default installation, the message "rpc.statd[<PID>]: Running as root. chown /var/lib/nfs to choose different user" appears in the syslog.
Wide netsearching did not find any recommendations but did find a lot of quoted logs with the message.
|
|
|
|
03-18-2012, 08:06 AM
|
#2
|
|
Moderator
Registered: May 2001
Posts: 24,970
|
Quote:
Originally Posted by catkin
Wide netsearching did not find any recommendations
|
So you didn't find https://bugzilla.redhat.com/show_bug.cgi?id=495066 ?
|
|
|
1 members found this post helpful.
|
03-18-2012, 10:29 AM
|
#3
|
|
LQ 5k Club
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Debian Squeeze (server), Slackware 13.37 (netbook), Slackware64 14.0 (desktop),
Posts: 8,367
Original Poster
|
Quote:
Originally Posted by unSpawn
|
I didn't and thanks for pointing it out
But I'm confuzzled after reading it, probably because of differences between Red Hat and Slackware. The bug is about ownership of /var/lib/nfs/statd/sm. The patch modifies the RPM's postinstall script to change it to rpcuser:rpcuser/700 (the unpatched postinstall script sets /var/lib/nfs/statd to rpcuser:rpcuser).
The syslog message on Slackware is about /var/lib/nfs. There is no /var/lib/nfs/statd/sm directory on Slackware64 13.1:
Code:
root@CW8:/var/lib/nfs# tree -dgu
.
|-- [nobody root ] sm
|-- [nobody root ] sm.bak
`-- [root root ] v4recovery
This is identical to a fresh installation.
The Red Hat/Slackware difference is probably explained by Slackware's nfs-utils' file.c having NSM_PATH_EXTENSION commented out:
Code:
/*
* Some distributions place statd's files in a subdirectory
*/
#define NSM_PATH_EXTENSION
/* #define NSM_PATH_EXTENSION "/statd" */
#define NSM_DEFAULT_STATEDIR NFS_STATEDIR NSM_PATH_EXTENSION
static char nsm_base_dirname[PATH_MAX] = NSM_DEFAULT_STATEDIR;
#define NSM_MONITOR_DIR "sm"
#define NSM_NOTIFY_DIR "sm.bak"
#define NSM_STATE_FILE "state"
Slackware does not have the rpcuser or group.
The message comes from
Code:
/**
* nsm_drop_privileges - drop root privileges
* @pidfd: file descriptor of a pid file
*
* Returns true if successful, or false if some error occurred.
*
* Set our effective UID and GID to that of our on-disk database.
*/
_Bool
nsm_drop_privileges(const int pidfd)
{
struct stat st;
(void)umask(S_IRWXO);
/*
* XXX: If we can't stat dirname, or if dirname is owned by
* root, we should use "statduser" instead, which is set up
* by configure.ac. Nothing in nfs-utils seems to use
* "statduser," though.
*/
if (lstat(nsm_base_dirname, &st) == -1) {
xlog(L_ERROR, "Failed to stat %s: %m", nsm_base_dirname);
return false;
}
if (st.st_uid == 0) {
xlog_warn("Running as root. "
"chown %s to choose different user", nsm_base_dirname);
return true;
In conclusion, Slackware's equivalent of Red Hat's /var/lib/nfs/statd/sm is /var/lib/nfs/sm and Slackware uses nobody:root where Read Hat uses rpcuser:rpcuser.
Which leaves the practical question "What can be done on Slackware to make rcp.statd run as other than root?".
This has become Slackware-specific. I am reporting this thread, requesting moving it to the Slackware forum.
Last edited by catkin; 03-18-2012 at 10:33 AM.
Reason: colouration
|
|
|
|
03-18-2012, 10:39 AM
|
#4
|
|
Moderator
Registered: May 2001
Posts: 24,970
|
IIRC the ticket says the process creates the directory and creating it and changing ownership beforehand lead to the desired outcome.
|
|
|
|
03-18-2012, 12:01 PM
|
#5
|
|
LQ 5k Club
Registered: Dec 2008
Location: Tamil Nadu, India
Distribution: Debian Squeeze (server), Slackware 13.37 (netbook), Slackware64 14.0 (desktop),
Posts: 8,367
Original Poster
|
Quote:
Originally Posted by unSpawn
IIRC the ticket says the process creates the directory and creating it and changing ownership beforehand lead to the desired outcome.
|
That could well be true. I can't be certain one way or another from reading the bug report or examining the patch -- but I have no familiarity with RPM architecture and practice.
|
|
|
|
03-19-2012, 11:28 AM
|
#6
|
|
Moderator
Registered: May 2001
Posts: 24,970
|
IMHO this has nothing to do with Red Hat or RPM knowledge: just test if deleting and creating the directory with the prefered user and group name before starting the process works.
|
|
|
|
01-09-2013, 06:35 AM
|
#7
|
|
LQ Newbie
Registered: Jun 2012
Posts: 8
Rep: 
|
Friendly bump
I cannot find any information on how to fix this problem. What is the current situation on this? Can somebody confirm if deleting the directory will fix the problem?
Last edited by houzi; 01-09-2013 at 06:37 AM.
Reason: Rephrasing my question.
|
|
|
|
01-09-2013, 06:44 AM
|
#8
|
|
Moderator
Registered: May 2001
Posts: 24,970
|
Can't you just try what was suggested?
|
|
|
|
01-09-2013, 06:26 PM
|
#9
|
|
LQ Newbie
Registered: Jun 2012
Posts: 8
Rep: 
|
Uncertain about what user/group to chown sm/ to
I tried to rename /var/lib/nfs/sm/ , hoping that some script would recreate it with the correct user/group. This did not work.
I have googled, read through the NFS HOWTO's in Slackware Wiki and in /usr/doc/Linux-HOWTOs/ , but I'm still clueless as to what user and/or group /var/lib/nfs/sm should have. Even though it's obviously a bad idea to use my own user and group, I tried this as well just to see if it helped, but still no go..
|
|
|
|
01-10-2013, 07:26 AM
|
#10
|
|
Moderator
Registered: May 2001
Posts: 24,970
|
Quote:
Originally Posted by houzi
(..) I'm still clueless as to what user and/or group /var/lib/nfs/sm should have.
|
Catkin concluded ownership of /var/lib/nfs/sm to be nobody:root?
|
|
|
|
01-10-2013, 08:23 AM
|
#11
|
|
LQ Newbie
Registered: Jun 2012
Posts: 8
Rep: 
|
OK - then the question still stands; how can we make Slackware securely run rpc.statd as non-root?
|
|
|
|
01-10-2013, 08:55 AM
|
#12
|
|
Moderator
Registered: May 2001
Posts: 24,970
|
Your 'man rpc.statd' will tell you the process needs to start as root to be able to create sockets and to access its database, and after initialization it drops privileges?
|
|
|
|
| Thread Tools |
Search this Thread |
|
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -5. The time now is 07:20 PM.
|
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|