All of lore.kernel.org
 help / color / mirror / Atom feed
* [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

* 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.