From trisk at omniti.com  Mon Aug 24 20:40:50 2015
From: trisk at omniti.com (Albert Lee)
Date: Mon, 24 Aug 2015 15:40:50 -0500
Subject: [Fakeroot-devel] chown on NFS mounts can produce EINVAL instead
 of EPERM
In-Reply-To: <20150823193136.GA2891@scru.org>
References: <CAN101LhCcDm3OzC2FJf5p+2V6RGLPaqTXv_T0u26Aif=V1iwKA@mail.gmail.com>
 <20150823193136.GA2891@scru.org>
Message-ID: <CAN101LiBCxet9B+y61U39k3O5-4wfgUFUGOLy=5+cZYj3xUCPQ@mail.gmail.com>

On Aug 23, 2015 2:31 PM, "Clint Adams" <clint at debian.org> wrote:
>
> On Sat, Aug 22, 2015 at 11:44:52AM -0500, Albert Lee wrote:
> > I've encountered problems constructing root filesystems with fakeroot
on NFS.
> >
> > The chown(2) family of syscalls produces EINVAL when a UID or GID is
> > "out of range". On an NFSv4 mount, this can occur when no name mapping
> > exists for the UID or GID. The real root user would also receive the
error.
> >
> > fakeroot only ignores EPERM at the moment. I believe it should be safe
> > to accept EINVAL and override policy on range restrictions here.
> >
> > Thoughts? (Hopefully someone is reading this list).
>
> Hi Albert,
>
> Which platform is this?  How do you suggest to handle situations wherein
> EINVAL is a useful error for the caller (like with fchown() on FreeBSD
> or fchownat() on Debian, perhaps)?

This is a Debian wheezy NFS client on a illumos (Solaris) server. Also
happens with Linux clients on other non-Linux NFSv4 servers, except for the
Linux NFSv4 server has an extension to bypass ID mapping. Other clients
seem to return EPERM in all cases. Good observation about the overloading
of EINVAL for other parameter checks, probably makes this a no-go for those
chown(2) variants.

-Albert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/fakeroot-devel/attachments/20150824/0f8da65f/attachment.html>