LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   rpc.statd: Running as root. chown /var/lib/nfs to choose different user (https://www.linuxquestions.org/questions/slackware-14/rpc-statd-running-as-root-chown-var-lib-nfs-to-choose-different-user-935042/)

catkin 03-18-2012 01:33 AM

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.

unSpawn 03-18-2012 08:06 AM

Quote:

Originally Posted by catkin (Post 4629574)
Wide netsearching did not find any recommendations

So you didn't find https://bugzilla.redhat.com/show_bug.cgi?id=495066 ?

catkin 03-18-2012 10:29 AM

Quote:

Originally Posted by unSpawn (Post 4629727)

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.

unSpawn 03-18-2012 10:39 AM

IIRC the ticket says the process creates the directory and creating it and changing ownership beforehand lead to the desired outcome.

catkin 03-18-2012 12:01 PM

Quote:

Originally Posted by unSpawn (Post 4629816)
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.

unSpawn 03-19-2012 11:28 AM

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.

houzi 01-09-2013 06:35 AM

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?

unSpawn 01-09-2013 06:44 AM

Can't you just try what was suggested?

houzi 01-09-2013 06:26 PM

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

unSpawn 01-10-2013 07:26 AM

Quote:

Originally Posted by houzi (Post 4866554)
(..) 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?

houzi 01-10-2013 08:23 AM

OK - then the question still stands; how can we make Slackware securely run rpc.statd as non-root?

unSpawn 01-10-2013 08:55 AM

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?


All times are GMT -5. The time now is 04:05 PM.