Quoting Eric W. Biederman ([email protected]):
> "Serge E. Hallyn" <[email protected]> writes:
>
> > Quoting Sam Vilain ([email protected]):
> >> Kirill Korotaev wrote:
> >>
> >> >Serge,
> >> >
> >> >BTW, have you noticed that NFS is using utsname for internal processes
> >> >and in general case this makes NFS ns to be coupled with uts ns?
> >> >
> >> >
> >>
> >> Either that, or each NFS vfsmount has a uts_ns pointer.
> >
> > Sorry, I must be being dense. I only see utsname being used in the case
> > of nfsroot. Can you point me to where you're talking about?
>
> We have the nfs lockd client code, and the sunrpc code.
>
> I've been fighting a few a cold and some 2.6.17-rc1 bugs
> so I haven't had a chance to drill down yet to see what
> the system_utsname.nodename is actually being used for.
>
> Until we actually understand what is happening it is too soon to
> judge if it is a problem or not.
>
> The nfsroot is clearly not a problem.
>
> As for the other cases I'm not certain.
>
> So skimming through the code quickly.
>
> include/linux/lockd/lockd.h
> > #define NLMCLNT_OHSIZE (sizeof(system_utsname.nodename)+10)
>
> fs/lockd/xdr.c
> > #define NLM_caller_sz 1+XDR_QUADLEN(sizeof(system_utsname.nodename))
>
> The previous two are just sizes, so not interesting for analysis.
>
>
> fs/lockd/clntproc.c
> > static void nlmclnt_setlockargs(struct nlm_rqst *req, struct file_lock *fl)
> > {
> > struct nlm_args *argp = &req->a_args;
> > struct nlm_lock *lock = &argp->lock;
> >
> > nlmclnt_next_cookie(&argp->cookie);
> > argp->state = nsm_local_state;
> > memcpy(&lock->fh, NFS_FH(fl->fl_file->f_dentry->d_inode), sizeof(struct nfs_fh));
> > lock->caller = system_utsname.nodename;
> > lock->oh.data = req->a_owner;
> > lock->oh.len = snprintf(req->a_owner, sizeof(req->a_owner), "%u@%s",
> > (unsigned int)fl->fl_u.nfs_fl.owner->pid,
> > system_utsname.nodename);
> > lock->svid = fl->fl_u.nfs_fl.owner->pid;
> > lock->fl.fl_start = fl->fl_start;
> > lock->fl.fl_end = fl->fl_end;
> > lock->fl.fl_type = fl->fl_type;
> > }
>
> I think this just creates a unique string with nodename+pid
In fs/lockd/svcshare.c, nlmsvc_share_file and nlmsvc_unshare_file do
compare the xdr_netobj->data field, which contains the snprinted
system_utsname.nodename.
However, if you're going to unshare utsname() and change your nodename,
the effect should be no different than if you just changed your
nodename :) So I don't see this being a problem.
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
