* [PATCH] cifs: Return the appropriate error in cifs_sb_tlink instead of a generic error. @ 2020-09-29 12:02 Shyam Prasad N 2020-09-29 13:16 ` Aurélien Aptel 0 siblings, 1 reply; 9+ messages in thread From: Shyam Prasad N @ 2020-09-29 12:02 UTC (permalink / raw) To: Steve French, CIFS, sribhat.msa, rohiths.msft [-- Attachment #1: Type: text/plain, Size: 664 bytes --] Hi Steve, Please find the attached patch for fixing the issue of returning hard coded EACCES when a new tcon needs to be established. This bug affects only the multiuser scenario. I've tested out this fix for a few scenarios: 1. User already has valid krb5 tickets, and mount is attempted. 2. User doesn't have krb5 tickets, and mount is attempted. 3. User has expired krb5 tickets, and mount is attempted. 4. The share is already mounted, and the mount point is accessed as another user who does not have valid krb5 tickets. 5. Same as 4, but created another session as same user (to validate the case of existing tcon). Please review the changes. -- -Shyam [-- Attachment #2: 0001-cifs-Return-the-appropriate-error-in-cifs_sb_tlink.patch --] [-- Type: application/octet-stream, Size: 1657 bytes --] From f634b932e480f76743fc9c4f1cab5500eefff898 Mon Sep 17 00:00:00 2001 From: Shyam Prasad N <sprasad@microsoft.com> Date: Tue, 29 Sep 2020 00:06:43 -0700 Subject: [PATCH] cifs: Return the appropriate error in cifs_sb_tlink instead of a generic error. Currently, cifs_sb_tlink returns a fixed errno EACCES when it fails for most reasons. This ends up masking the error returned by cifs_construct_tcon, which will have a more meaningful error for the failure. One of the cases where this behaviour is confusing is where a new tcon needs to be constructed, but it fails due to expired keys. cifs_construct_tcon then returns ENOKEY, but we end up returning a EACCES to the user. Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> --- fs/cifs/connect.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c index 1a3b7793095e..5fda76f41404 100644 --- a/fs/cifs/connect.c +++ b/fs/cifs/connect.c @@ -5475,8 +5475,9 @@ cifs_sb_tlink(struct cifs_sb_info *cifs_sb) /* return error if we tried this already recently */ if (time_before(jiffies, tlink->tl_time + TLINK_ERROR_EXPIRE)) { + newtlink = (struct tcon_link *) tlink->tl_tcon; cifs_put_tlink(tlink); - return ERR_PTR(-EACCES); + return newtlink; } if (test_and_set_bit(TCON_LINK_PENDING, &tlink->tl_flags)) @@ -5488,8 +5489,9 @@ cifs_sb_tlink(struct cifs_sb_info *cifs_sb) wake_up_bit(&tlink->tl_flags, TCON_LINK_PENDING); if (IS_ERR(tlink->tl_tcon)) { + newtlink = (struct tcon_link *) tlink->tl_tcon; cifs_put_tlink(tlink); - return ERR_PTR(-EACCES); + return newtlink; } return tlink; -- 2.25.1 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] cifs: Return the appropriate error in cifs_sb_tlink instead of a generic error. 2020-09-29 12:02 [PATCH] cifs: Return the appropriate error in cifs_sb_tlink instead of a generic error Shyam Prasad N @ 2020-09-29 13:16 ` Aurélien Aptel 2020-09-29 17:46 ` Steve French 0 siblings, 1 reply; 9+ messages in thread From: Aurélien Aptel @ 2020-09-29 13:16 UTC (permalink / raw) To: Shyam Prasad N, Steve French, CIFS, sribhat.msa, rohiths.msft Shyam Prasad N <nspmangalore@gmail.com> writes: > One of the cases where this behaviour is confusing is where a > new tcon needs to be constructed, but it fails due to > expired keys. cifs_construct_tcon then returns ENOKEY, > but we end up returning a EACCES to the user. > > Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> LGTM Reviewed-by: Aurelien Aptel <aaptel@suse.com> Cheers, -- Aurélien Aptel / SUSE Labs Samba Team GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] cifs: Return the appropriate error in cifs_sb_tlink instead of a generic error. 2020-09-29 13:16 ` Aurélien Aptel @ 2020-09-29 17:46 ` Steve French 2020-09-30 15:18 ` Shyam Prasad N 0 siblings, 1 reply; 9+ messages in thread From: Steve French @ 2020-09-29 17:46 UTC (permalink / raw) To: Aurélien Aptel; +Cc: Shyam Prasad N, CIFS, sribhat.msa, rohiths msft tentatively merged ... running the usual functional tests http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/399 On Tue, Sep 29, 2020 at 8:16 AM Aurélien Aptel <aaptel@suse.com> wrote: > > Shyam Prasad N <nspmangalore@gmail.com> writes: > > One of the cases where this behaviour is confusing is where a > > new tcon needs to be constructed, but it fails due to > > expired keys. cifs_construct_tcon then returns ENOKEY, > > but we end up returning a EACCES to the user. > > > > Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> > > LGTM > > Reviewed-by: Aurelien Aptel <aaptel@suse.com> > > Cheers, > -- > Aurélien Aptel / SUSE Labs Samba Team > GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 > SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München) -- Thanks, Steve ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] cifs: Return the appropriate error in cifs_sb_tlink instead of a generic error. 2020-09-29 17:46 ` Steve French @ 2020-09-30 15:18 ` Shyam Prasad N 2020-09-30 15:57 ` Shyam Prasad N 0 siblings, 1 reply; 9+ messages in thread From: Shyam Prasad N @ 2020-09-30 15:18 UTC (permalink / raw) To: Steve French, ronnie sahlberg Cc: Aurélien Aptel, CIFS, sribhat.msa, rohiths msft It looks like xfstests smb3 multiuser cifsutils-101 and cifs-101 are failing. Maybe they were written keeping in mind the current error code returned by cifs.ko in this situation? Let me take a look. I guess @ronnie sahlberg will be able to debug the failing tests faster. The failing test has his name in the code. :) On Tue, Sep 29, 2020 at 11:16 PM Steve French <smfrench@gmail.com> wrote: > > tentatively merged ... running the usual functional tests > http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/399 > > On Tue, Sep 29, 2020 at 8:16 AM Aurélien Aptel <aaptel@suse.com> wrote: > > > > Shyam Prasad N <nspmangalore@gmail.com> writes: > > > One of the cases where this behaviour is confusing is where a > > > new tcon needs to be constructed, but it fails due to > > > expired keys. cifs_construct_tcon then returns ENOKEY, > > > but we end up returning a EACCES to the user. > > > > > > Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> > > > > LGTM > > > > Reviewed-by: Aurelien Aptel <aaptel@suse.com> > > > > Cheers, > > -- > > Aurélien Aptel / SUSE Labs Samba Team > > GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 > > SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE > > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München) > > > > -- > Thanks, > > Steve -- -Shyam ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] cifs: Return the appropriate error in cifs_sb_tlink instead of a generic error. 2020-09-30 15:18 ` Shyam Prasad N @ 2020-09-30 15:57 ` Shyam Prasad N 2020-09-30 23:16 ` ronnie sahlberg 0 siblings, 1 reply; 9+ messages in thread From: Shyam Prasad N @ 2020-09-30 15:57 UTC (permalink / raw) To: Steve French, ronnie sahlberg Cc: Aurélien Aptel, CIFS, sribhat.msa, rohiths msft Ok. Checked the test. It does a multiuser mount of a file share. (I'm assuming this is using sec=ntlmssp) Then does an "ls" on the mount point as another user. Expects EACCES as the output. With this change, the command returns an ENOKEY. With the credentials added to keyring using cifscreds, the ls command works. Now the question is: Is the right error to return here EACCES or ENOKEY? Even if the expected error here should be EACCES, I'd say that the error returned by cifs_set_cifscreds should return that error. Regards, Shyam On Wed, Sep 30, 2020 at 8:48 PM Shyam Prasad N <nspmangalore@gmail.com> wrote: > > It looks like xfstests smb3 multiuser cifsutils-101 and cifs-101 are failing. > Maybe they were written keeping in mind the current error code > returned by cifs.ko in this situation? Let me take a look. > I guess @ronnie sahlberg will be able to debug the failing tests > faster. The failing test has his name in the code. :) > > On Tue, Sep 29, 2020 at 11:16 PM Steve French <smfrench@gmail.com> wrote: > > > > tentatively merged ... running the usual functional tests > > http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/399 > > > > On Tue, Sep 29, 2020 at 8:16 AM Aurélien Aptel <aaptel@suse.com> wrote: > > > > > > Shyam Prasad N <nspmangalore@gmail.com> writes: > > > > One of the cases where this behaviour is confusing is where a > > > > new tcon needs to be constructed, but it fails due to > > > > expired keys. cifs_construct_tcon then returns ENOKEY, > > > > but we end up returning a EACCES to the user. > > > > > > > > Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> > > > > > > LGTM > > > > > > Reviewed-by: Aurelien Aptel <aaptel@suse.com> > > > > > > Cheers, > > > -- > > > Aurélien Aptel / SUSE Labs Samba Team > > > GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 > > > SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE > > > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München) > > > > > > > > -- > > Thanks, > > > > Steve > > > > -- > -Shyam -- -Shyam ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] cifs: Return the appropriate error in cifs_sb_tlink instead of a generic error. 2020-09-30 15:57 ` Shyam Prasad N @ 2020-09-30 23:16 ` ronnie sahlberg 2020-10-01 5:12 ` Shyam Prasad N 0 siblings, 1 reply; 9+ messages in thread From: ronnie sahlberg @ 2020-09-30 23:16 UTC (permalink / raw) To: Shyam Prasad N Cc: Steve French, Aurélien Aptel, CIFS, sribhat.msa, rohiths msft On Thu, Oct 1, 2020 at 1:57 AM Shyam Prasad N <nspmangalore@gmail.com> wrote: > > Ok. Checked the test. It does a multiuser mount of a file share. (I'm > assuming this is using sec=ntlmssp) > Then does an "ls" on the mount point as another user. Expects EACCES > as the output. > With this change, the command returns an ENOKEY. > With the credentials added to keyring using cifscreds, the ls command works. > > Now the question is: Is the right error to return here EACCES or > ENOKEY? Even if the expected error here should be EACCES, I'd say that > the error returned by cifs_set_cifscreds should return that error. > Good find! I am leaning towards leaving it as EACCES as that is a generic "you dont have access" errno we report back to userspace. System calls like opendir(), stat() etc all list EACCES as a valid return code but they don't list ENOKEY. So we then have to consider the applications. For applications that don't look at errno it wouldn't matter but for applications that do look at errno and try to take proper action to failures would be "surprised" since they get an errno that is not listed on the manpage. So that is why I think we should leave it as -EACCES as this is the generic "you don't have access". But we should make sure that when this happens we do get a more detailed "you don't have access because you don't have proper credentials" into log-file / dmesg. Regards Ronnie > Regards, > Shyam > > On Wed, Sep 30, 2020 at 8:48 PM Shyam Prasad N <nspmangalore@gmail.com> wrote: > > > > It looks like xfstests smb3 multiuser cifsutils-101 and cifs-101 are failing. > > Maybe they were written keeping in mind the current error code > > returned by cifs.ko in this situation? Let me take a look. > > I guess @ronnie sahlberg will be able to debug the failing tests > > faster. The failing test has his name in the code. :) > > > > On Tue, Sep 29, 2020 at 11:16 PM Steve French <smfrench@gmail.com> wrote: > > > > > > tentatively merged ... running the usual functional tests > > > http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/399 > > > > > > On Tue, Sep 29, 2020 at 8:16 AM Aurélien Aptel <aaptel@suse.com> wrote: > > > > > > > > Shyam Prasad N <nspmangalore@gmail.com> writes: > > > > > One of the cases where this behaviour is confusing is where a > > > > > new tcon needs to be constructed, but it fails due to > > > > > expired keys. cifs_construct_tcon then returns ENOKEY, > > > > > but we end up returning a EACCES to the user. > > > > > > > > > > Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> > > > > > > > > LGTM > > > > > > > > Reviewed-by: Aurelien Aptel <aaptel@suse.com> > > > > > > > > Cheers, > > > > -- > > > > Aurélien Aptel / SUSE Labs Samba Team > > > > GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 > > > > SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE > > > > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München) > > > > > > > > > > > > -- > > > Thanks, > > > > > > Steve > > > > > > > > -- > > -Shyam > > > > -- > -Shyam ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] cifs: Return the appropriate error in cifs_sb_tlink instead of a generic error. 2020-09-30 23:16 ` ronnie sahlberg @ 2020-10-01 5:12 ` Shyam Prasad N [not found] ` <CAH2r5mtyE7+X6ayp8FfzWu5cyengtd=RMFD0XimZPFoJQ5h+PQ@mail.gmail.com> 0 siblings, 1 reply; 9+ messages in thread From: Shyam Prasad N @ 2020-10-01 5:12 UTC (permalink / raw) To: ronnie sahlberg Cc: Steve French, Aurélien Aptel, CIFS, sribhat.msa, rohiths msft Hi Ronnie, Returning EACCES to userspace does make sense. However, with the current code, even a ENOMEM or EIO will return a EACCES to userspace. I'm thinking that we need to specifically map ENOKEY to EACCES here. I was discussing this with Steve yesterday, and he suggested that I email fs-devel about what is the general expectation from VFS. Regards, Shyam On Thu, Oct 1, 2020 at 4:47 AM ronnie sahlberg <ronniesahlberg@gmail.com> wrote: > > On Thu, Oct 1, 2020 at 1:57 AM Shyam Prasad N <nspmangalore@gmail.com> wrote: > > > > Ok. Checked the test. It does a multiuser mount of a file share. (I'm > > assuming this is using sec=ntlmssp) > > Then does an "ls" on the mount point as another user. Expects EACCES > > as the output. > > With this change, the command returns an ENOKEY. > > With the credentials added to keyring using cifscreds, the ls command works. > > > > Now the question is: Is the right error to return here EACCES or > > ENOKEY? Even if the expected error here should be EACCES, I'd say that > > the error returned by cifs_set_cifscreds should return that error. > > > > Good find! > > I am leaning towards leaving it as EACCES as that is a generic "you > dont have access" errno we report back to userspace. > System calls like opendir(), stat() etc all list EACCES as a valid > return code but they don't list ENOKEY. > So we then have to consider the applications. For applications that > don't look at errno it wouldn't matter but for applications that do > look at errno and try to take proper action to failures would be > "surprised" since they get an errno that is not listed on the manpage. > > So that is why I think we should leave it as -EACCES as this is the > generic "you don't have access". > But we should make sure that when this happens we do get a more > detailed "you don't have access because you don't have proper > credentials" into log-file / dmesg. > > Regards > Ronnie > > > Regards, > > Shyam > > > > On Wed, Sep 30, 2020 at 8:48 PM Shyam Prasad N <nspmangalore@gmail.com> wrote: > > > > > > It looks like xfstests smb3 multiuser cifsutils-101 and cifs-101 are failing. > > > Maybe they were written keeping in mind the current error code > > > returned by cifs.ko in this situation? Let me take a look. > > > I guess @ronnie sahlberg will be able to debug the failing tests > > > faster. The failing test has his name in the code. :) > > > > > > On Tue, Sep 29, 2020 at 11:16 PM Steve French <smfrench@gmail.com> wrote: > > > > > > > > tentatively merged ... running the usual functional tests > > > > http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/399 > > > > > > > > On Tue, Sep 29, 2020 at 8:16 AM Aurélien Aptel <aaptel@suse.com> wrote: > > > > > > > > > > Shyam Prasad N <nspmangalore@gmail.com> writes: > > > > > > One of the cases where this behaviour is confusing is where a > > > > > > new tcon needs to be constructed, but it fails due to > > > > > > expired keys. cifs_construct_tcon then returns ENOKEY, > > > > > > but we end up returning a EACCES to the user. > > > > > > > > > > > > Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> > > > > > > > > > > LGTM > > > > > > > > > > Reviewed-by: Aurelien Aptel <aaptel@suse.com> > > > > > > > > > > Cheers, > > > > > -- > > > > > Aurélien Aptel / SUSE Labs Samba Team > > > > > GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 > > > > > SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE > > > > > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München) > > > > > > > > > > > > > > > > -- > > > > Thanks, > > > > > > > > Steve > > > > > > > > > > > > -- > > > -Shyam > > > > > > > > -- > > -Shyam -- -Shyam ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <CAH2r5mtyE7+X6ayp8FfzWu5cyengtd=RMFD0XimZPFoJQ5h+PQ@mail.gmail.com>]
* Re: [PATCH] cifs: Return the appropriate error in cifs_sb_tlink instead of a generic error. [not found] ` <CAH2r5mtyE7+X6ayp8FfzWu5cyengtd=RMFD0XimZPFoJQ5h+PQ@mail.gmail.com> @ 2020-10-01 10:42 ` Shyam Prasad N 2020-10-01 11:29 ` ronnie sahlberg 0 siblings, 1 reply; 9+ messages in thread From: Shyam Prasad N @ 2020-10-01 10:42 UTC (permalink / raw) To: Steve French Cc: ronnie sahlberg, Aurélien Aptel, CIFS, sribhat.msa, rohiths msft Ronnie does make a good point about the error returned to the user. However, masking all the errors returned from the cifs_construct_tcon() doesn't sit well with me. For example, if the system is low on memory, or there's an EIO returned due to some reason, those errors will not make it to the user, and the user will see a blanket "Permission denied". How many Linux users will check the dmesg/logs when they get an EACCES? Moreover, if the actual returned is ENOMEM but we return EACCES to the user, we could have a situation where the user gets EACCES for one I/O but no such error for the subsequent I/O. This can be quite confusing for the user. Opinions? Regards, Shyam On Thu, Oct 1, 2020 at 10:55 AM Steve French <smfrench@gmail.com> wrote: > > Ronnie makes a good point about checking valid return codes by api call (open, close, read, write) as well ... > > On Thu, Oct 1, 2020 at 12:13 AM Shyam Prasad N <nspmangalore@gmail.com> wrote: >> >> Hi Ronnie, >> >> Returning EACCES to userspace does make sense. However, with the >> current code, even a ENOMEM or EIO will return a EACCES to userspace. >> I'm thinking that we need to specifically map ENOKEY to EACCES here. >> >> I was discussing this with Steve yesterday, and he suggested that I >> email fs-devel about what is the general expectation from VFS. >> >> Regards, >> Shyam >> >> On Thu, Oct 1, 2020 at 4:47 AM ronnie sahlberg <ronniesahlberg@gmail.com> wrote: >> > >> > On Thu, Oct 1, 2020 at 1:57 AM Shyam Prasad N <nspmangalore@gmail.com> wrote: >> > > >> > > Ok. Checked the test. It does a multiuser mount of a file share. (I'm >> > > assuming this is using sec=ntlmssp) >> > > Then does an "ls" on the mount point as another user. Expects EACCES >> > > as the output. >> > > With this change, the command returns an ENOKEY. >> > > With the credentials added to keyring using cifscreds, the ls command works. >> > > >> > > Now the question is: Is the right error to return here EACCES or >> > > ENOKEY? Even if the expected error here should be EACCES, I'd say that >> > > the error returned by cifs_set_cifscreds should return that error. >> > > >> > >> > Good find! >> > >> > I am leaning towards leaving it as EACCES as that is a generic "you >> > dont have access" errno we report back to userspace. >> > System calls like opendir(), stat() etc all list EACCES as a valid >> > return code but they don't list ENOKEY. >> > So we then have to consider the applications. For applications that >> > don't look at errno it wouldn't matter but for applications that do >> > look at errno and try to take proper action to failures would be >> > "surprised" since they get an errno that is not listed on the manpage. >> > >> > So that is why I think we should leave it as -EACCES as this is the >> > generic "you don't have access". >> > But we should make sure that when this happens we do get a more >> > detailed "you don't have access because you don't have proper >> > credentials" into log-file / dmesg. >> > >> > Regards >> > Ronnie >> > >> > > Regards, >> > > Shyam >> > > >> > > On Wed, Sep 30, 2020 at 8:48 PM Shyam Prasad N <nspmangalore@gmail.com> wrote: >> > > > >> > > > It looks like xfstests smb3 multiuser cifsutils-101 and cifs-101 are failing. >> > > > Maybe they were written keeping in mind the current error code >> > > > returned by cifs.ko in this situation? Let me take a look. >> > > > I guess @ronnie sahlberg will be able to debug the failing tests >> > > > faster. The failing test has his name in the code. :) >> > > > >> > > > On Tue, Sep 29, 2020 at 11:16 PM Steve French <smfrench@gmail.com> wrote: >> > > > > >> > > > > tentatively merged ... running the usual functional tests >> > > > > http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/399 >> > > > > >> > > > > On Tue, Sep 29, 2020 at 8:16 AM Aurélien Aptel <aaptel@suse.com> wrote: >> > > > > > >> > > > > > Shyam Prasad N <nspmangalore@gmail.com> writes: >> > > > > > > One of the cases where this behaviour is confusing is where a >> > > > > > > new tcon needs to be constructed, but it fails due to >> > > > > > > expired keys. cifs_construct_tcon then returns ENOKEY, >> > > > > > > but we end up returning a EACCES to the user. >> > > > > > > >> > > > > > > Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> >> > > > > > >> > > > > > LGTM >> > > > > > >> > > > > > Reviewed-by: Aurelien Aptel <aaptel@suse.com> >> > > > > > >> > > > > > Cheers, >> > > > > > -- >> > > > > > Aurélien Aptel / SUSE Labs Samba Team >> > > > > > GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 >> > > > > > SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE >> > > > > > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München) >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Thanks, >> > > > > >> > > > > Steve >> > > > >> > > > >> > > > >> > > > -- >> > > > -Shyam >> > > >> > > >> > > >> > > -- >> > > -Shyam >> >> >> >> -- >> -Shyam > > > > -- > Thanks, > > Steve -- -Shyam ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] cifs: Return the appropriate error in cifs_sb_tlink instead of a generic error. 2020-10-01 10:42 ` Shyam Prasad N @ 2020-10-01 11:29 ` ronnie sahlberg 0 siblings, 0 replies; 9+ messages in thread From: ronnie sahlberg @ 2020-10-01 11:29 UTC (permalink / raw) To: Shyam Prasad N Cc: Steve French, Aurélien Aptel, CIFS, sribhat.msa, rohiths msft On Thu, Oct 1, 2020 at 8:42 PM Shyam Prasad N <nspmangalore@gmail.com> wrote: > > Ronnie does make a good point about the error returned to the user. > However, masking all the errors returned from the > cifs_construct_tcon() doesn't sit well with me. > > For example, if the system is low on memory, or there's an EIO > returned due to some reason, those errors will not make it to the > user, and the user will see a blanket "Permission denied". How many > Linux users will check the dmesg/logs when they get an EACCES? > > Moreover, if the actual returned is ENOMEM but we return EACCES to the > user, we could have a situation where the user gets EACCES for one I/O > but no such error for the subsequent I/O. This can be quite confusing > for the user. It is primarily about making sure that applications do not misbehave. Especially applications or glibc that do pay close attention to what errno is when a syscall fails. And where errno drives them how to handle or manage recovery. It basically depends on case by case scenario. Are applications calling this syscall directly or via glibc. If the latter, what errnos does glibc accept for that syscall and how does it deal with them? The answer here is what the man page says, because that is what application and glibc are coded against. We can not introduce new errno values to userspace. There may be situations where currently we leak "unexpected" errno values through syscalls. That would be a bug and we need to fix it. In cifs.ko we have had very serious bugs in the past where we were leaking "unexpected" errno values to either glibc or application that turned what should be a simple recoverable error into a serious hard Data-Loss failure :-(. By causing glibc/application recovery code to be "surprised" and to fail recovery. Very sad. The way imho opinion to prevent confusion to end user is to log warning with explanation to dmesg or log file. If user caser, user looks at dmesg/log. If user does not care, that is fine. As long as we do not "surprise" glibc or application. We make sure we return only those errnos in the manpage and from there it is the responsibility of glibc/application to handle it. > > Opinions? > > Regards, > Shyam > > On Thu, Oct 1, 2020 at 10:55 AM Steve French <smfrench@gmail.com> wrote: > > > > Ronnie makes a good point about checking valid return codes by api call (open, close, read, write) as well ... > > > > On Thu, Oct 1, 2020 at 12:13 AM Shyam Prasad N <nspmangalore@gmail.com> wrote: > >> > >> Hi Ronnie, > >> > >> Returning EACCES to userspace does make sense. However, with the > >> current code, even a ENOMEM or EIO will return a EACCES to userspace. > >> I'm thinking that we need to specifically map ENOKEY to EACCES here. > >> > >> I was discussing this with Steve yesterday, and he suggested that I > >> email fs-devel about what is the general expectation from VFS. > >> > >> Regards, > >> Shyam > >> > >> On Thu, Oct 1, 2020 at 4:47 AM ronnie sahlberg <ronniesahlberg@gmail.com> wrote: > >> > > >> > On Thu, Oct 1, 2020 at 1:57 AM Shyam Prasad N <nspmangalore@gmail.com> wrote: > >> > > > >> > > Ok. Checked the test. It does a multiuser mount of a file share. (I'm > >> > > assuming this is using sec=ntlmssp) > >> > > Then does an "ls" on the mount point as another user. Expects EACCES > >> > > as the output. > >> > > With this change, the command returns an ENOKEY. > >> > > With the credentials added to keyring using cifscreds, the ls command works. > >> > > > >> > > Now the question is: Is the right error to return here EACCES or > >> > > ENOKEY? Even if the expected error here should be EACCES, I'd say that > >> > > the error returned by cifs_set_cifscreds should return that error. > >> > > > >> > > >> > Good find! > >> > > >> > I am leaning towards leaving it as EACCES as that is a generic "you > >> > dont have access" errno we report back to userspace. > >> > System calls like opendir(), stat() etc all list EACCES as a valid > >> > return code but they don't list ENOKEY. > >> > So we then have to consider the applications. For applications that > >> > don't look at errno it wouldn't matter but for applications that do > >> > look at errno and try to take proper action to failures would be > >> > "surprised" since they get an errno that is not listed on the manpage. > >> > > >> > So that is why I think we should leave it as -EACCES as this is the > >> > generic "you don't have access". > >> > But we should make sure that when this happens we do get a more > >> > detailed "you don't have access because you don't have proper > >> > credentials" into log-file / dmesg. > >> > > >> > Regards > >> > Ronnie > >> > > >> > > Regards, > >> > > Shyam > >> > > > >> > > On Wed, Sep 30, 2020 at 8:48 PM Shyam Prasad N <nspmangalore@gmail.com> wrote: > >> > > > > >> > > > It looks like xfstests smb3 multiuser cifsutils-101 and cifs-101 are failing. > >> > > > Maybe they were written keeping in mind the current error code > >> > > > returned by cifs.ko in this situation? Let me take a look. > >> > > > I guess @ronnie sahlberg will be able to debug the failing tests > >> > > > faster. The failing test has his name in the code. :) > >> > > > > >> > > > On Tue, Sep 29, 2020 at 11:16 PM Steve French <smfrench@gmail.com> wrote: > >> > > > > > >> > > > > tentatively merged ... running the usual functional tests > >> > > > > http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/399 > >> > > > > > >> > > > > On Tue, Sep 29, 2020 at 8:16 AM Aurélien Aptel <aaptel@suse.com> wrote: > >> > > > > > > >> > > > > > Shyam Prasad N <nspmangalore@gmail.com> writes: > >> > > > > > > One of the cases where this behaviour is confusing is where a > >> > > > > > > new tcon needs to be constructed, but it fails due to > >> > > > > > > expired keys. cifs_construct_tcon then returns ENOKEY, > >> > > > > > > but we end up returning a EACCES to the user. > >> > > > > > > > >> > > > > > > Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> > >> > > > > > > >> > > > > > LGTM > >> > > > > > > >> > > > > > Reviewed-by: Aurelien Aptel <aaptel@suse.com> > >> > > > > > > >> > > > > > Cheers, > >> > > > > > -- > >> > > > > > Aurélien Aptel / SUSE Labs Samba Team > >> > > > > > GPG: 1839 CB5F 9F5B FB9B AA97 8C99 03C8 A49B 521B D5D3 > >> > > > > > SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE > >> > > > > > GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 247165 (AG München) > >> > > > > > >> > > > > > >> > > > > > >> > > > > -- > >> > > > > Thanks, > >> > > > > > >> > > > > Steve > >> > > > > >> > > > > >> > > > > >> > > > -- > >> > > > -Shyam > >> > > > >> > > > >> > > > >> > > -- > >> > > -Shyam > >> > >> > >> > >> -- > >> -Shyam > > > > > > > > -- > > Thanks, > > > > Steve > > > > -- > -Shyam ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-10-01 11:29 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-29 12:02 [PATCH] cifs: Return the appropriate error in cifs_sb_tlink instead of a generic error Shyam Prasad N
2020-09-29 13:16 ` Aurélien Aptel
2020-09-29 17:46 ` Steve French
2020-09-30 15:18 ` Shyam Prasad N
2020-09-30 15:57 ` Shyam Prasad N
2020-09-30 23:16 ` ronnie sahlberg
2020-10-01 5:12 ` Shyam Prasad N
[not found] ` <CAH2r5mtyE7+X6ayp8FfzWu5cyengtd=RMFD0XimZPFoJQ5h+PQ@mail.gmail.com>
2020-10-01 10:42 ` Shyam Prasad N
2020-10-01 11:29 ` ronnie sahlberg
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.