Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: acls+kerberos (limitation)
From:   Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <CAN-5tyEv4UTfCmkkrYFnOB7nHAV8qX7opfSb=RJT_=PA5tih4g@mail.gmail.com>
Date:   Fri, 20 Dec 2019 13:28:05 -0500
Cc:     Trond Myklebust <trondmy@hammerspace.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E086E39A-E140-420F-87CA-A6959F301AD8@oracle.com>
References: <CAN-5tyHJLh8+htpb47Uz+ojo5EfrpP=zyE-Vfk=HjvBgK591=g@mail.gmail.com>
 <f4595e80487d9ace332e2ae69bc0c539a5c029bb.camel@hammerspace.com>
 <CAN-5tyGXUhhZVkrBxTwGP-Y2FXoMdN9kYtc9r0wS8P8EQuxyoQ@mail.gmail.com>
 <C5067A0A-5FA4-4FC0-B5B6-828EB3E83373@oracle.com>
 <CAN-5tyEv4UTfCmkkrYFnOB7nHAV8qX7opfSb=RJT_=PA5tih4g@mail.gmail.com>
To:     Olga Kornievskaia <aglo@umich.edu>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


> On Dec 20, 2019, at 1:15 PM, Olga Kornievskaia <aglo@umich.edu> wrote:
>=20
> On Wed, Dec 18, 2019 at 2:34 PM Chuck Lever <chuck.lever@oracle.com> =
wrote:
>>=20
>>=20
>>=20
>>> On Dec 18, 2019, at 2:31 PM, Olga Kornievskaia <aglo@umich.edu> =
wrote:
>>>=20
>>> On Wed, Dec 18, 2019 at 2:05 PM Trond Myklebust =
<trondmy@hammerspace.com> wrote:
>>>>=20
>>>> On Wed, 2019-12-18 at 12:47 -0500, Olga Kornievskaia wrote:
>>>>> Hi folks,
>>>>>=20
>>>>> Is this a well know but undocumented fact that you can't set large
>>>>> amount of acls (over 4096bytes, ~90acls) while mounted using
>>>>> krb5i/krb5p? That if you want to get/set large acls, it must be =
done
>>>>> over auth_sys/krb5?
>>>>>=20
>>>>=20
>>>> It's certainly not something that I was aware of. Do you see where =
that
>>>> limitation is coming from?
>>>=20
>>> I haven't figure it exactly but gss_unwrap_resp_integ() is failing =
in
>>> if (mic_offset > rcv_buf->len). I'm just not sure who sets up the
>>> buffer (or why  rvc_buf->len is (4280) larger than a page can a
>>> page-limit might make sense to for me but it's not). So you think it
>>> should have been working.
>>=20
>> The buffer is set up in the XDR encoder. But pages can be added
>> by the transport... I guess rcv_buf->len isn't updated when that
>> happens.
>>=20
>=20
> Here's why the acl+krbi/krb5p is failing.
>=20
> acl tool first calls into the kernel to find out how large of a buffer
> it needs to supply and gets acl size then calls down again then code
> in __nfs4_get_acl_uncached() allocates a number of pages (this what
> set's the available buffer length later used by the sunrpc code). That
> works for non-integrity because in call_decode() the call
> rpc_unwrap_resp() doesn't try to calculate the checksum on the buffer
> that was just read. However, when its krb5i/krb5p we have truncated
> buffer and mic offset that's larger than the existing buffer.
>=20
> I think something needs to be marked to skip doing gss for the initial
> acl query?  I first try providing more space in
> __nfs4_get_acl_uncached() for when authflavor=3Dkrb5i/krb5p and =
buflen=3D0
> but no matter what the number is the received acl can be larger than
> that thus I don't think that's a good approach.

It's not strictly true that the received ACL can be always be larger.
There is an upper bound on request sizes.

My preference has always been to allocate a receive buffer of the =
maximum
size before the call, just like every other request works. I can't think
of any reason why retrieving an ACL has to be different. Then we can get
rid of the hack in the transports to fill in those pages behind the back
of the upper layers.

The issue here has always been that there's no way for the client to
discover the number of bytes it needs to retrieve before it sets up the
GETACL.

For NFSv4.1+ you can probably assume that the ACL will never be larger
than the session's maximum reply size.

For NFSv4.0 you'll have to make something up.

But allocating a large receive buffer for this request is the only way =
to
make the receive reliable. You should be able to do that by stuffing the
recv XDR buffer with individual pages, just like nfsd does, in GETACL's
encoding function.

Others might have a different opinion. Or I might have completely
misunderstood the issue.


--
Chuck Lever