| Message ID | 161456493684.22801.323431390819102360.stgit@noble (mailing list archive) |
|---|---|
| Headers | show |
| Series | nfs-utils: provide audit-logging of NFSv4 access | expand |
Hi NeilBrown, Shall we further add these 2 options (cache-use-ipaddr & ttl) with their default values to the file /etc/nfs.conf under section [mountd]? By which the users can find it easier to configure them. Also someone may check the mountd "Recognized values" from nfs.conf(5), the file systemd/nfs.conf.man may also needs to be updated mentioning "cache-use-ipaddr" and "ttl" IMHO. Thanks, Yongcheng On Mon, Mar 01, 2021 at 01:17:15PM +1100, NeilBrown wrote: > V1 of this series didn't update the usage() message for mountd, > and omited the required ':' after the 'T' sort-option. This > series fixes those two omissions. > > Original series comment: > > When NFSv3 is used mountd provides logs of successful and failed mount > attempts which can be used for auditing. > When NFSv4 is used there are no such logs as NFSv4 does not have a > distinct "mount" request. > > However mountd still knows about which filesysytems are being accessed > from which clients, and can actually provide more reliable logs than it > currently does, though they must be more verbose - with periodic "is > being accessed" message replacing a single "was mounted" message. > > This series adds support for that logging, and adds some related > improvements to make the logs as useful as possible. > > NeilBrown > > --- > > NeilBrown (5): > mountd: reject unknown client IP when !use_ipaddr. > mountd: Don't proactively add export info when fh info is requested. > mountd: add logging for authentication results for accesses. > mountd: add --cache-use-ipaddr option to force use_ipaddr > mountd: make default ttl settable by option > > > support/export/auth.c | 4 +++ > support/export/cache.c | 32 +++++++++++------ > support/export/v4root.c | 3 +- > support/include/exportfs.h | 3 +- > support/nfs/exports.c | 4 ++- > utils/mountd/mountd.c | 30 +++++++++++++++- > utils/mountd/mountd.man | 70 ++++++++++++++++++++++++++++++++++++++ > 7 files changed, 131 insertions(+), 15 deletions(-) > > -- > Signature >
I've gotten requests for similar functionality, and intended to implement it using directory notifications on /proc/fs/nfsd/clients. But this is another way to do it that I hadn't thought of. That's interesting. I haven't thought about the relative advantages or disadvantages. --b. On Mon, Mar 01, 2021 at 01:17:15PM +1100, NeilBrown wrote: > V1 of this series didn't update the usage() message for mountd, > and omited the required ':' after the 'T' sort-option. This > series fixes those two omissions. > > Original series comment: > > When NFSv3 is used mountd provides logs of successful and failed mount > attempts which can be used for auditing. > When NFSv4 is used there are no such logs as NFSv4 does not have a > distinct "mount" request. > > However mountd still knows about which filesysytems are being accessed > from which clients, and can actually provide more reliable logs than it > currently does, though they must be more verbose - with periodic "is > being accessed" message replacing a single "was mounted" message. > > This series adds support for that logging, and adds some related > improvements to make the logs as useful as possible. > > NeilBrown > > --- > > NeilBrown (5): > mountd: reject unknown client IP when !use_ipaddr. > mountd: Don't proactively add export info when fh info is requested. > mountd: add logging for authentication results for accesses. > mountd: add --cache-use-ipaddr option to force use_ipaddr > mountd: make default ttl settable by option > > > support/export/auth.c | 4 +++ > support/export/cache.c | 32 +++++++++++------ > support/export/v4root.c | 3 +- > support/include/exportfs.h | 3 +- > support/nfs/exports.c | 4 ++- > utils/mountd/mountd.c | 30 +++++++++++++++- > utils/mountd/mountd.man | 70 ++++++++++++++++++++++++++++++++++++++ > 7 files changed, 131 insertions(+), 15 deletions(-) > > -- > Signature
On Mon, Mar 01 2021, J. Bruce Fields wrote: > I've gotten requests for similar functionality, and intended to > implement it using directory notifications on /proc/fs/nfsd/clients. Interesting idea. That could report successful mounts and unmounts but wouldn't report failed mount attempts or (I think) which export point is being mounted. If we could reliably correlate the entry in 'clients' with each auth request, we could filter out multiple auth refresh requests for the same client+filesystem. The only field we could do that on would be IP address, and that wouldn't be seamless.. Might be worth pursuing if only to report "mount" and "unmount" events for a client identified by IP, and leave it to the admin to see any connection between 'mount' events and 'auth' events. Thanks, NeilBrown > > But this is another way to do it that I hadn't thought of. That's > interesting. I haven't thought about the relative advantages or > disadvantages. > > --b. > > On Mon, Mar 01, 2021 at 01:17:15PM +1100, NeilBrown wrote: >> V1 of this series didn't update the usage() message for mountd, >> and omited the required ':' after the 'T' sort-option. This >> series fixes those two omissions. >> >> Original series comment: >> >> When NFSv3 is used mountd provides logs of successful and failed mount >> attempts which can be used for auditing. >> When NFSv4 is used there are no such logs as NFSv4 does not have a >> distinct "mount" request. >> >> However mountd still knows about which filesysytems are being accessed >> from which clients, and can actually provide more reliable logs than it >> currently does, though they must be more verbose - with periodic "is >> being accessed" message replacing a single "was mounted" message. >> >> This series adds support for that logging, and adds some related >> improvements to make the logs as useful as possible. >> >> NeilBrown >> >> --- >> >> NeilBrown (5): >> mountd: reject unknown client IP when !use_ipaddr. >> mountd: Don't proactively add export info when fh info is requested. >> mountd: add logging for authentication results for accesses. >> mountd: add --cache-use-ipaddr option to force use_ipaddr >> mountd: make default ttl settable by option >> >> >> support/export/auth.c | 4 +++ >> support/export/cache.c | 32 +++++++++++------ >> support/export/v4root.c | 3 +- >> support/include/exportfs.h | 3 +- >> support/nfs/exports.c | 4 ++- >> utils/mountd/mountd.c | 30 +++++++++++++++- >> utils/mountd/mountd.man | 70 ++++++++++++++++++++++++++++++++++++++ >> 7 files changed, 131 insertions(+), 15 deletions(-) >> >> -- >> Signature
On Mon, Mar 01 2021, Yongcheng Yang wrote: > Hi NeilBrown, > > Shall we further add these 2 options (cache-use-ipaddr & ttl) with > their default values to the file /etc/nfs.conf under section [mountd]? > By which the users can find it easier to configure them. > > Also someone may check the mountd "Recognized values" from > nfs.conf(5), the file systemd/nfs.conf.man may also needs to be > updated mentioning "cache-use-ipaddr" and "ttl" IMHO. Excellent suggestion, thanks. I've made those changes and will resend the series. Thanks, NeilBrown > > Thanks, > Yongcheng > > > On Mon, Mar 01, 2021 at 01:17:15PM +1100, NeilBrown wrote: >> V1 of this series didn't update the usage() message for mountd, >> and omited the required ':' after the 'T' sort-option. This >> series fixes those two omissions. >> >> Original series comment: >> >> When NFSv3 is used mountd provides logs of successful and failed mount >> attempts which can be used for auditing. >> When NFSv4 is used there are no such logs as NFSv4 does not have a >> distinct "mount" request. >> >> However mountd still knows about which filesysytems are being accessed >> from which clients, and can actually provide more reliable logs than it >> currently does, though they must be more verbose - with periodic "is >> being accessed" message replacing a single "was mounted" message. >> >> This series adds support for that logging, and adds some related >> improvements to make the logs as useful as possible. >> >> NeilBrown >> >> --- >> >> NeilBrown (5): >> mountd: reject unknown client IP when !use_ipaddr. >> mountd: Don't proactively add export info when fh info is requested. >> mountd: add logging for authentication results for accesses. >> mountd: add --cache-use-ipaddr option to force use_ipaddr >> mountd: make default ttl settable by option >> >> >> support/export/auth.c | 4 +++ >> support/export/cache.c | 32 +++++++++++------ >> support/export/v4root.c | 3 +- >> support/include/exportfs.h | 3 +- >> support/nfs/exports.c | 4 ++- >> utils/mountd/mountd.c | 30 +++++++++++++++- >> utils/mountd/mountd.man | 70 ++++++++++++++++++++++++++++++++++++++ >> 7 files changed, 131 insertions(+), 15 deletions(-) >> >> -- >> Signature >>
On Mon, Mar 01 2021, J. Bruce Fields wrote: > I've gotten requests for similar functionality, and intended to > implement it using directory notifications on /proc/fs/nfsd/clients. I've been exploring this a bit. When I mount a filesystem, 2 clients get created. With NFSv4.0, the second client is immediately deleted, and the first client is deleted one grace period after the filesystem is unmounted. With NFSv4.1 and 4.2, the first client is immediately deleted, and the second client is deleted immediately after the unmount. Do you know why two clients are created? I could dig through the code ... but maybe you already know. Thanks, NeilBrown
On Tue, Mar 02, 2021 at 02:01:36PM +1100, NeilBrown wrote: > On Mon, Mar 01 2021, J. Bruce Fields wrote: > > > I've gotten requests for similar functionality, and intended to > > implement it using directory notifications on /proc/fs/nfsd/clients. > > I've been exploring this a bit. > When I mount a filesystem, 2 clients get created. > With NFSv4.0, the second client is immediately deleted, and the first > client is deleted one grace period after the filesystem is unmounted. > With NFSv4.1 and 4.2, the first client is immediately deleted, and the > second client is deleted immediately after the unmount. Yeah, internally it's creating an "unconfirmed client" on SETCLIENTID (or EXCHANGE_ID) and then a new "confirmed client" on SETCLIENTID_CONFIRM (or CREATE_SESSION). I'm not sure why the ordering's a little different between the 4.0/4.1+ cases. The difference on unmount is because 4.1+ clients immediately send a DESTROY_CLIENTID on unmount, but that op was new to 4.1. (Note of course this isn't precisely mount/unmount, as the same client can be used for multiple filesystems.) Honestly, I think this is exposing an implementation detail and it's dumb. I'll look into fixing it. (I don't know if that change itself would cause additional difficulty.) --b.
On Mon, Mar 01 2021, J. Bruce Fields wrote: > On Tue, Mar 02, 2021 at 02:01:36PM +1100, NeilBrown wrote: >> On Mon, Mar 01 2021, J. Bruce Fields wrote: >> >> > I've gotten requests for similar functionality, and intended to >> > implement it using directory notifications on /proc/fs/nfsd/clients. >> >> I've been exploring this a bit. >> When I mount a filesystem, 2 clients get created. >> With NFSv4.0, the second client is immediately deleted, and the first >> client is deleted one grace period after the filesystem is unmounted. >> With NFSv4.1 and 4.2, the first client is immediately deleted, and the >> second client is deleted immediately after the unmount. > > Yeah, internally it's creating an "unconfirmed client" on SETCLIENTID > (or EXCHANGE_ID) and then a new "confirmed client" on > SETCLIENTID_CONFIRM (or CREATE_SESSION). Of course - the "confirm" step. That would explain it. > > I'm not sure why the ordering's a little different between the 4.0/4.1+ > cases. > > The difference on unmount is because 4.1+ clients immediately send a > DESTROY_CLIENTID on unmount, but that op was new to 4.1. I thought it would be something like that - a protocol improvements. > > (Note of course this isn't precisely mount/unmount, as the same client > can be used for multiple filesystems.) True. It could also be a network disconnect, not an explicit unmount. Still I think it could be useful to log. > > Honestly, I think this is exposing an implementation detail and it's > dumb. I'll look into fixing it. Thanks. > > (I don't know if that change itself would cause additional difficulty.) I doubt it. You would need to look at "info" in a directory to do anything useful, and in my simple testing that always said cat: /proc/fs/nfsd/clients/41/info: No such file or directory or similar in the transient directory. So code is mostly likely to quickly ignore any such directory. I'll see how easy it is to add "client added" and "client removed" log messages to mountd before resending my series. Thanks, NeilBrown
On Tue, Mar 02, 2021 at 02:49:13PM +1100, NeilBrown wrote: > I'll see how easy it is to add "client added" and "client removed" log > messages to mountd before resending my series. OK, thanks again for doing this! Also if there's more information we could add to those "info" files to make it easier to correlate with the authentication upcalls, that should be easy to do.... --b.
On Mon, Mar 01 2021, J. Bruce Fields wrote: > On Tue, Mar 02, 2021 at 02:01:36PM +1100, NeilBrown wrote: >> On Mon, Mar 01 2021, J. Bruce Fields wrote: >> >> > I've gotten requests for similar functionality, and intended to >> > implement it using directory notifications on /proc/fs/nfsd/clients. >> >> I've been exploring this a bit. >> When I mount a filesystem, 2 clients get created. >> With NFSv4.0, the second client is immediately deleted, and the first >> client is deleted one grace period after the filesystem is unmounted. >> With NFSv4.1 and 4.2, the first client is immediately deleted, and the >> second client is deleted immediately after the unmount. > > Yeah, internally it's creating an "unconfirmed client" on SETCLIENTID > (or EXCHANGE_ID) and then a new "confirmed client" on > SETCLIENTID_CONFIRM (or CREATE_SESSION). > > I'm not sure why the ordering's a little different between the 4.0/4.1+ > cases. The multiple clients are not really nfsd's "fault". The Linux NFS client sends multiple EXCHANGE_ID or SET_CLIENT_ID requests, so NFSD really does need to create multiple clients. For NFSv4.0, when nfsd gets a repeat SET_CLIENT_ID, it keeps the old one and discards the new. For NFSv4.1, the spec requires that it keep the new one and discard the old. This explains the different ordering. So the clean up the logging, mountd needs to be able to see the confirmation status. Following this reply will be a patch to nfsd to provide this status, and a patch to mountd/exportd to use this status. Thanks, NeilBrown
On Fri, Mar 19, 2021 at 02:36:24PM +1100, NeilBrown wrote: > On Mon, Mar 01 2021, J. Bruce Fields wrote: > > > On Tue, Mar 02, 2021 at 02:01:36PM +1100, NeilBrown wrote: > >> On Mon, Mar 01 2021, J. Bruce Fields wrote: > >> > >> > I've gotten requests for similar functionality, and intended to > >> > implement it using directory notifications on /proc/fs/nfsd/clients. > >> > >> I've been exploring this a bit. > >> When I mount a filesystem, 2 clients get created. > >> With NFSv4.0, the second client is immediately deleted, and the first > >> client is deleted one grace period after the filesystem is unmounted. > >> With NFSv4.1 and 4.2, the first client is immediately deleted, and the > >> second client is deleted immediately after the unmount. > > > > Yeah, internally it's creating an "unconfirmed client" on SETCLIENTID > > (or EXCHANGE_ID) and then a new "confirmed client" on > > SETCLIENTID_CONFIRM (or CREATE_SESSION). > > > > I'm not sure why the ordering's a little different between the 4.0/4.1+ > > cases. > > The multiple clients are not really nfsd's "fault". The Linux NFS > client sends multiple EXCHANGE_ID or SET_CLIENT_ID requests, so NFSD > really does need to create multiple clients. > > For NFSv4.0, when nfsd gets a repeat SET_CLIENT_ID, it keeps the old one > and discards the new. > For NFSv4.1, the spec requires that it keep the new one and discard the > old. > This explains the different ordering. Hm, is this the client's trunking-detection logic? In which case, it's not just unconfirmed clients. > So the clean up the logging, mountd needs to be able to see the > confirmation status. That sounds fine. (The other possibility might be to just not expose clients till they're confirmed. I don't know if unconfirmed clients are really that interesting. But I guess I'd rather err on the side of exposing more information here.) > Following this reply will be a patch to nfsd to provide this status, and > a patch to mountd/exportd to use this status.
On Fri, Mar 19 2021, J. Bruce Fields wrote: > On Fri, Mar 19, 2021 at 02:36:24PM +1100, NeilBrown wrote: >> On Mon, Mar 01 2021, J. Bruce Fields wrote: >> >> > On Tue, Mar 02, 2021 at 02:01:36PM +1100, NeilBrown wrote: >> >> On Mon, Mar 01 2021, J. Bruce Fields wrote: >> >> >> >> > I've gotten requests for similar functionality, and intended to >> >> > implement it using directory notifications on /proc/fs/nfsd/clients. >> >> >> >> I've been exploring this a bit. >> >> When I mount a filesystem, 2 clients get created. >> >> With NFSv4.0, the second client is immediately deleted, and the first >> >> client is deleted one grace period after the filesystem is unmounted. >> >> With NFSv4.1 and 4.2, the first client is immediately deleted, and the >> >> second client is deleted immediately after the unmount. >> > >> > Yeah, internally it's creating an "unconfirmed client" on SETCLIENTID >> > (or EXCHANGE_ID) and then a new "confirmed client" on >> > SETCLIENTID_CONFIRM (or CREATE_SESSION). >> > >> > I'm not sure why the ordering's a little different between the 4.0/4.1+ >> > cases. >> >> The multiple clients are not really nfsd's "fault". The Linux NFS >> client sends multiple EXCHANGE_ID or SET_CLIENT_ID requests, so NFSD >> really does need to create multiple clients. >> >> For NFSv4.0, when nfsd gets a repeat SET_CLIENT_ID, it keeps the old one >> and discards the new. >> For NFSv4.1, the spec requires that it keep the new one and discard the >> old. >> This explains the different ordering. > > Hm, is this the client's trunking-detection logic? Yes. > > In which case, it's not just unconfirmed clients. For NFSv4.1, only the EXCHANGE_ID is duplicate. There is only one CREATE_SESSION, and that is where the client is confirmed. So only one confirmed client. For NFSv4.0 bother SETCLIENTID and SETCLIENDID_CONFIRM are duplicate. So maybe both clients get confirmed. I should check that. > >> So the clean up the logging, mountd needs to be able to see the >> confirmation status. > > That sounds fine. > > (The other possibility might be to just not expose clients till they're > confirmed. I don't know if unconfirmed clients are really that > interesting. But I guess I'd rather err on the side of exposing more > information here.) That was my feeling to: expose all the info, and filter out the uninteresting bits a point of use. Thanks, NeilBrown > >> Following this reply will be a patch to nfsd to provide this status, and >> a patch to mountd/exportd to use this status.
On Sat, Mar 20, 2021 at 07:48:44AM +1100, NeilBrown wrote: > On Fri, Mar 19 2021, J. Bruce Fields wrote: > > > On Fri, Mar 19, 2021 at 02:36:24PM +1100, NeilBrown wrote: > >> On Mon, Mar 01 2021, J. Bruce Fields wrote: > >> > >> > On Tue, Mar 02, 2021 at 02:01:36PM +1100, NeilBrown wrote: > >> >> On Mon, Mar 01 2021, J. Bruce Fields wrote: > >> >> > >> >> > I've gotten requests for similar functionality, and intended to > >> >> > implement it using directory notifications on /proc/fs/nfsd/clients. > >> >> > >> >> I've been exploring this a bit. > >> >> When I mount a filesystem, 2 clients get created. > >> >> With NFSv4.0, the second client is immediately deleted, and the first > >> >> client is deleted one grace period after the filesystem is unmounted. > >> >> With NFSv4.1 and 4.2, the first client is immediately deleted, and the > >> >> second client is deleted immediately after the unmount. > >> > > >> > Yeah, internally it's creating an "unconfirmed client" on SETCLIENTID > >> > (or EXCHANGE_ID) and then a new "confirmed client" on > >> > SETCLIENTID_CONFIRM (or CREATE_SESSION). > >> > > >> > I'm not sure why the ordering's a little different between the 4.0/4.1+ > >> > cases. > >> > >> The multiple clients are not really nfsd's "fault". The Linux NFS > >> client sends multiple EXCHANGE_ID or SET_CLIENT_ID requests, so NFSD > >> really does need to create multiple clients. > >> > >> For NFSv4.0, when nfsd gets a repeat SET_CLIENT_ID, it keeps the old one > >> and discards the new. > >> For NFSv4.1, the spec requires that it keep the new one and discard the > >> old. > >> This explains the different ordering. > > > > Hm, is this the client's trunking-detection logic? > > Yes. > > > > > In which case, it's not just unconfirmed clients. > > For NFSv4.1, only the EXCHANGE_ID is duplicate. There is only one > CREATE_SESSION, and that is where the client is confirmed. So only one > confirmed client. > > For NFSv4.0 bother SETCLIENTID and SETCLIENDID_CONFIRM are duplicate. > So maybe both clients get confirmed. I should check that. Drifting off topic, but I don't see how this client behavior makes sense. Mount is chatty enough without the unnecessary duplication. Looking at the code.... --b.
On Fri, Mar 19, 2021 at 05:09:22PM -0400, J. Bruce Fields wrote: > On Sat, Mar 20, 2021 at 07:48:44AM +1100, NeilBrown wrote: > > For NFSv4.1, only the EXCHANGE_ID is duplicate. There is only one > > CREATE_SESSION, and that is where the client is confirmed. So only one > > confirmed client. > > > > For NFSv4.0 bother SETCLIENTID and SETCLIENDID_CONFIRM are duplicate. > > So maybe both clients get confirmed. I should check that. > > Drifting off topic, but I don't see how this client behavior makes > sense. Mount is chatty enough without the unnecessary duplication. > Looking at the code.... I spent a little time tracing through the code and couldn't figure out what's going on. Just a note for the future that it'd be worth figuring out why the client is repeating SETCLIENTID+SETCLIENTID_CONFIRM or EXCHANGE_ID+CREATE_SESSION. I understand why it might be needed for trunking detection when there are multiple addresses involved, but otherwise it seems unnecessary. --b.
On Fri, Mar 19, 2021 at 05:09:22PM -0400, J. Bruce Fields wrote: > On Sat, Mar 20, 2021 at 07:48:44AM +1100, NeilBrown wrote: > > On Fri, Mar 19 2021, J. Bruce Fields wrote: > > > > > On Fri, Mar 19, 2021 at 02:36:24PM +1100, NeilBrown wrote: > > >> On Mon, Mar 01 2021, J. Bruce Fields wrote: > > >> > > >> > On Tue, Mar 02, 2021 at 02:01:36PM +1100, NeilBrown wrote: > > >> >> On Mon, Mar 01 2021, J. Bruce Fields wrote: > > >> >> > > >> >> > I've gotten requests for similar functionality, and intended to > > >> >> > implement it using directory notifications on /proc/fs/nfsd/clients. > > >> >> > > >> >> I've been exploring this a bit. > > >> >> When I mount a filesystem, 2 clients get created. > > >> >> With NFSv4.0, the second client is immediately deleted, and the first > > >> >> client is deleted one grace period after the filesystem is unmounted. > > >> >> With NFSv4.1 and 4.2, the first client is immediately deleted, and the > > >> >> second client is deleted immediately after the unmount. > > >> > > > >> > Yeah, internally it's creating an "unconfirmed client" on SETCLIENTID > > >> > (or EXCHANGE_ID) and then a new "confirmed client" on > > >> > SETCLIENTID_CONFIRM (or CREATE_SESSION). > > >> > > > >> > I'm not sure why the ordering's a little different between the 4.0/4.1+ > > >> > cases. > > >> > > >> The multiple clients are not really nfsd's "fault". The Linux NFS > > >> client sends multiple EXCHANGE_ID or SET_CLIENT_ID requests, so NFSD > > >> really does need to create multiple clients. > > >> > > >> For NFSv4.0, when nfsd gets a repeat SET_CLIENT_ID, it keeps the old one > > >> and discards the new. > > >> For NFSv4.1, the spec requires that it keep the new one and discard the > > >> old. > > >> This explains the different ordering. > > > > > > Hm, is this the client's trunking-detection logic? > > > > Yes. > > > > > > > > In which case, it's not just unconfirmed clients. > > > > For NFSv4.1, only the EXCHANGE_ID is duplicate. There is only one > > CREATE_SESSION, and that is where the client is confirmed. So only one > > confirmed client. > > > > For NFSv4.0 bother SETCLIENTID and SETCLIENDID_CONFIRM are duplicate. > > So maybe both clients get confirmed. I should check that. > > Drifting off topic, but I don't see how this client behavior makes > sense. Mount is chatty enough without the unnecessary duplication. > Looking at the code.... I never sorted this out, by the way. I think there must be a bug, though. --b.
On 4/7/21 3:14 PM, J. Bruce Fields wrote: > On Fri, Mar 19, 2021 at 05:09:22PM -0400, J. Bruce Fields wrote: >> On Sat, Mar 20, 2021 at 07:48:44AM +1100, NeilBrown wrote: >>> On Fri, Mar 19 2021, J. Bruce Fields wrote: >>> >>>> On Fri, Mar 19, 2021 at 02:36:24PM +1100, NeilBrown wrote: >>>>> On Mon, Mar 01 2021, J. Bruce Fields wrote: >>>>> >>>>>> On Tue, Mar 02, 2021 at 02:01:36PM +1100, NeilBrown wrote: >>>>>>> On Mon, Mar 01 2021, J. Bruce Fields wrote: >>>>>>> >>>>>>>> I've gotten requests for similar functionality, and intended to >>>>>>>> implement it using directory notifications on /proc/fs/nfsd/clients. >>>>>>> >>>>>>> I've been exploring this a bit. >>>>>>> When I mount a filesystem, 2 clients get created. >>>>>>> With NFSv4.0, the second client is immediately deleted, and the first >>>>>>> client is deleted one grace period after the filesystem is unmounted. >>>>>>> With NFSv4.1 and 4.2, the first client is immediately deleted, and the >>>>>>> second client is deleted immediately after the unmount. >>>>>> >>>>>> Yeah, internally it's creating an "unconfirmed client" on SETCLIENTID >>>>>> (or EXCHANGE_ID) and then a new "confirmed client" on >>>>>> SETCLIENTID_CONFIRM (or CREATE_SESSION). >>>>>> >>>>>> I'm not sure why the ordering's a little different between the 4.0/4.1+ >>>>>> cases. >>>>> >>>>> The multiple clients are not really nfsd's "fault". The Linux NFS >>>>> client sends multiple EXCHANGE_ID or SET_CLIENT_ID requests, so NFSD >>>>> really does need to create multiple clients. >>>>> >>>>> For NFSv4.0, when nfsd gets a repeat SET_CLIENT_ID, it keeps the old one >>>>> and discards the new. >>>>> For NFSv4.1, the spec requires that it keep the new one and discard the >>>>> old. >>>>> This explains the different ordering. >>>> >>>> Hm, is this the client's trunking-detection logic? >>> >>> Yes. >>> >>>> >>>> In which case, it's not just unconfirmed clients. >>> >>> For NFSv4.1, only the EXCHANGE_ID is duplicate. There is only one >>> CREATE_SESSION, and that is where the client is confirmed. So only one >>> confirmed client. >>> >>> For NFSv4.0 bother SETCLIENTID and SETCLIENDID_CONFIRM are duplicate. >>> So maybe both clients get confirmed. I should check that. >> >> Drifting off topic, but I don't see how this client behavior makes >> sense. Mount is chatty enough without the unnecessary duplication. >> Looking at the code.... > > I never sorted this out, by the way. I think there must be a bug, > though. My bad... I didn't realize you had concern with the patch... What needs to happen... to figure this out? steved.
On Wed, Apr 07, 2021 at 03:33:41PM -0400, Steve Dickson wrote: > > > On 4/7/21 3:14 PM, J. Bruce Fields wrote: > > On Fri, Mar 19, 2021 at 05:09:22PM -0400, J. Bruce Fields wrote: > >> On Sat, Mar 20, 2021 at 07:48:44AM +1100, NeilBrown wrote: > >>> For NFSv4.1, only the EXCHANGE_ID is duplicate. There is only one > >>> CREATE_SESSION, and that is where the client is confirmed. So only one > >>> confirmed client. > >>> > >>> For NFSv4.0 bother SETCLIENTID and SETCLIENDID_CONFIRM are duplicate. > >>> So maybe both clients get confirmed. I should check that. > >> > >> Drifting off topic, but I don't see how this client behavior makes > >> sense. Mount is chatty enough without the unnecessary duplication. > >> Looking at the code.... > > > > I never sorted this out, by the way. I think there must be a bug, > > though. > My bad... I didn't realize you had concern with the patch... > What needs to happen... to figure this out? Sorry, it wasn't a concern with Neil's patches. The thing I don't understand is why the client is sending these calls twice. Anyway, that's more-or-less harmless behavior, and in kernel code, nothing to do with nfs-utils. --b.
V1 of this series didn't update the usage() message for mountd, and omited the required ':' after the 'T' sort-option. This series fixes those two omissions. Original series comment: When NFSv3 is used mountd provides logs of successful and failed mount attempts which can be used for auditing. When NFSv4 is used there are no such logs as NFSv4 does not have a distinct "mount" request. However mountd still knows about which filesysytems are being accessed from which clients, and can actually provide more reliable logs than it currently does, though they must be more verbose - with periodic "is being accessed" message replacing a single "was mounted" message. This series adds support for that logging, and adds some related improvements to make the logs as useful as possible. NeilBrown --- NeilBrown (5): mountd: reject unknown client IP when !use_ipaddr. mountd: Don't proactively add export info when fh info is requested. mountd: add logging for authentication results for accesses. mountd: add --cache-use-ipaddr option to force use_ipaddr mountd: make default ttl settable by option support/export/auth.c | 4 +++ support/export/cache.c | 32 +++++++++++------ support/export/v4root.c | 3 +- support/include/exportfs.h | 3 +- support/nfs/exports.c | 4 ++- utils/mountd/mountd.c | 30 +++++++++++++++- utils/mountd/mountd.man | 70 ++++++++++++++++++++++++++++++++++++++ 7 files changed, 131 insertions(+), 15 deletions(-) -- Signature