[linux-cifs-client] Re: Errors relating to expiration of account or password

Jeff Layton jlayton at redhat.com
Thu Oct 18 18:50:16 GMT 2007


On Thu, 18 Oct 2007 13:21:55 -0500
"Steve French" <smfrench at gmail.com> wrote:

> Ratelimit might make sense on cERROR (need to find examples of that
> lockd/host.c did not look like the best example) but it turns out we
> logged once on error on setup_session errors (even on reconnect) -
> this will make it twice (but only in the case in which 32 bit NT
> STATUS codes are negotiated and in which the error is on
> SMBSessionSetup and is not more processing required).  On mount it
> gets logged once more on error.
> 
> Sample output with patch installed:
> for mount with
> 1) inactive account with bad password specified (otherwise guest
> sesssetup would happen)
> 2) account expired
> 3) account not allowed to logon during these logon hours
> 
> smf-t60p:/home/stevef/cifs-2.6 # dmesg
> Status code returned 0xc000006d NT_STATUS_LOGON_FAILURE
>  CIFS VFS: Send error in SessSetup = -13
>  CIFS VFS: cifs_mount failed w/return code = -13
> Status code returned 0xc0000193 NT_STATUS_ACCOUNT_EXPIRED
>  CIFS VFS: Send error in SessSetup = -127
>  CIFS VFS: cifs_mount failed w/return code = -127
> Status code returned 0xc000006f NT_STATUS_INVALID_LOGON_HOURS
>  CIFS VFS: Send error in SessSetup = -13
>  CIFS VFS: cifs_mount failed w/return code = -13
> 
> 
> 
> Comments about the patch?
> 
> 
> 
> On 10/18/07, Jeff Layton <jlayton at redhat.com> wrote:
> > On Thu, 18 Oct 2007 11:59:18 -0500
> > "Steve French" <smfrench at gmail.com> wrote:
> >
> > > Yes - the key errors may be the best bet -
> > >
> > > Am also considering whether I should add a flag to the mpx entry
> > > that indicates "requesting call wants pre-mapped errors to be
> > > logged - ie the nt status codes when non-zero - but this requires
> > > parsing out the expected cases like "MORE_PROCESSING_REQUIRED") -
> > > if I add  a flag and have map_smb_to_linux_error honor it on
> > > logging - then at least dmesg will have good info for a few
> > > common cases but are there any expected cases in which this would
> > > make SessionSetup too noisy or worse lots of reconnect retries of
> > > SessionSetup fill the log?
> > >
> >
> > You can always ratelimit. Might be good to add a new
> > cERROR_ratelimit macro anyway...
> >
> > > On 10/18/07, Jeff Layton <jlayton at redhat.com> wrote:
> > > > On Thu, 18 Oct 2007 10:10:35 -0500
> > > > "Steve French" <smfrench at gmail.com> wrote:
> > > >
> > > > > Any idea whether we should use the keyctl api to return errors
> > > > > such as pwexpired on reconnect?  For example, we could launch
> > > > > a helper that pops up gnome or kde message to alert the user.
> > > > >
> > > >
> > > > Hmm possibly...might also make it possible to have multiuser
> > > > mounts without kerberos. The downside is that there's no
> > > > guarantee the user will have X running, but I suppose you could
> > > > just have request-key return error if you can't pop up the
> > > > right request.
> > > >
> > > > > This is also a problem on mount due to the inability to pass
> > > > > useful info back on the mount api response.
> > > > >
> > > >
> > > > This is a big issue for a lot of reasons. mount() is very
> > > > generic and a lot of filesystems would like to pass extra info
> > > > back to userspace. Maybe it's time to consider a mount2() that
> > > > accepts a __user pointer and a size_t? Not that I need a new
> > > > project, mind you ;-)
> > > >
> > > > > Any idea whether we have an obscure posix errors we could map
> > > > > to the various expired conditions (something better than
> > > > > EACCESS)?
> > > >
> > > > Maybe:
> > > >
> > > > #define EKEYEXPIRED     127     /* Key has expired */
> > > >
> > > > ...though and it's not really the "key" that's expired. Still,
> > > > probably the most descriptive error of the lot.
> > > >
> > > > >  In any
> > > > > case - I think we need to special case log these in session
> > > > > setup
> > > > > - but I am a bit worried about reconnect storms logging these
> > > > > multiple times and how to prevent that.  Unfortunately since
> > > > > they get mapped to EACCESS by the time we return in
> > > > > sessionsetup we will have to special case them.
> > > > >
> > > > > IRC snippet follows:
> > > > >  smfrench: I have been looking at the error handling on
> > > > > various expired errors (password expired, account expired,
> > > > > account inactive) and noticed some interesting things.   Why
> > > > > does Windows allow SessionSetup on an account marked inactive
> > > > > ie "NET USER inactive-user /ACTIVE:NO"
> > > > > (10:06:33) smfrench: it allows it as Guest ... but it does not
> > > > > return an error as it does when the account is expired
> > > > > (10:06:58) smfrench: ie "NET USER
> > > > > expired-user /EXPIRES:10/01/07" (10:07:15) smfrench: when you
> > > > > net use to that you get an error onSessSetup
> > > > > (STATUS_ACCOUNT_EXPIRED of course) (10:08:57) smfrench: And
> > > > > in trying to see what the flags were for this user I noticed
> > > > > that the Samba "net" command does not return an error on
> > > > > "./net user" when it fails with access denied (10:09:10)
> > > > > smfrench: (just returns an empty list)
> > > > >
> > > >
> > > >
> > > > --
> > > > Jeff Layton <jlayton at redhat.com>
> > > >
> > >
> > >
> >
> >
> > --
> > Jeff Layton <jlayton at redhat.com>
> >
> 
> 

ACK on the idea. I think I would have made a new function for the new
behavior rather than add a flag. Maybe something like:

map_and_log_smb_err

...but that's really a minor nitpick.

-- 
Jeff Layton <jlayton at redhat.com>


More information about the linux-cifs-client mailing list