All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shyam Prasad N <nspmangalore@gmail.com>
To: Stefan Metzmacher <metze@samba.org>
Cc: Steve French <smfrench@gmail.com>,
	Enzo Matsumiya <ematsumiya@suse.de>,
	CIFS <linux-cifs@vger.kernel.org>, Paulo Alcantara <pc@cjr.nz>
Subject: Re: [PATCH] cifs: send workstation name during ntlmssp session setup
Date: Mon, 8 Nov 2021 12:41:25 +0530	[thread overview]
Message-ID: <CANT5p=r6c+1Zmc9DysK1c6TPMVJ1QhW5+z1G3gDf1fvXpHyj_w@mail.gmail.com> (raw)
In-Reply-To: <bf98a745-5feb-c38a-4641-6dd91c364c8e@samba.org>

Hi Stefan,

Good points. Please read my replies inline below.

On Sun, Nov 7, 2021 at 4:19 PM Stefan Metzmacher <metze@samba.org> wrote:
>
>
> Hi Shyam,
>
> >>>> Please review this patch, and let me know what you think.
> >>>> Having this info in the workstation field of session setup helps
> >>>> server debugging in two ways.
> >>>> 1. It helps identify the client by node name.
> >>>> 2. It helps get the kernel release running on the client side.
> >>>>
> >>>> https://github.com/sprasad-microsoft/smb3-kernel-client/commit/d988e704dd9170c19ff94d9421c017e65dbbaac1.patch
> >>>
> >>> - AFAICS it doesn't consider runtime hostname changes. Is it important
> >>>    to keep track of it? Would changing it mid-auth steps break it
> >>>    somehow?
> > I think that's okay. AFAIK, that's only used for
> > debugging/troubleshooting purposes. So it doesn't need to be a 100%
> > accurate.
>
> That's not true, the workstation name is used for access checks.
>
> [MS-ADA3] 2.353 Attribute userWorkstations
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-ada3/ec941bac-bc77-48f3-a1cf-79d773a91b6b
>
I see.
So ideally we should be setting the FQDN of the client here. I don't
know if there's a way to get the FQDN from within the kernel.
I'll just set the utsname()->nodename for now. If someone has better
ideas, feel free to chime in.

> >>>
> >>> - I didn't understand the purpose of CIFS_DEFAULT_WORKSTATION_NAME. Why
> >>>    not simply use utsname()->nodename? Or even init_utsname()->nodename, which
> >>>    is supposed to be always valid.
> > I initially did not have the utsname changes. That idea was an afterthought.
> > Sure. I'll update the patch to fix this.
> >
> >>>
> >>> - Ditto for CIFS_MAX_WORKSTATION_LEN. utsname()->nodename has at most 65
> >>>    bytes (__NEW_UTS_LEN + 1) anyway. Perhaps using MAXHOSTNAMELEN from
> >>>    <asm/param.h> would be a more generic approach.
> >>>    (btw this is because nodename is the unqualified hostname, sans-domain)
> > Noted.
> >
> >>>
> >>> - Instead of setting workstation_name to "nodename:release", why not
> >>>    implement the VERSION structure (MS-NLMP 2.2.2.10)? Then use
> >>>    LINUX_VERSION_* from <linux/version.h> or parse utsname()->release.
> > That's a good idea. Let me explore that too.
>
> No, it's not this is for windows version numbers.
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/a211d894-21bc-4b8b-86ba-b83d0c167b00#Appendix_A_32
>
> If you want to encode something you can use
> 2.2.2.2 Single_Host_Data
>
> metze

Thanks for the tip. I'll explore this option for a future fix.

-- 
Regards,
Shyam

      reply	other threads:[~2021-11-08  7:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-05 19:22 [PATCH] cifs: send workstation name during ntlmssp session setup Shyam Prasad N
2021-11-06  1:38 ` Enzo Matsumiya
     [not found]   ` <CAH2r5mvQG0DFmMdzojH2u_w2=_9oGRV++AnEt_d7WJzj=-uTKA@mail.gmail.com>
2021-11-06  3:38     ` Shyam Prasad N
2021-11-06  7:02       ` Shyam Prasad N
2021-11-07 10:49       ` Stefan Metzmacher
2021-11-08  7:11         ` Shyam Prasad N [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANT5p=r6c+1Zmc9DysK1c6TPMVJ1QhW5+z1G3gDf1fvXpHyj_w@mail.gmail.com' \
    --to=nspmangalore@gmail.com \
    --cc=ematsumiya@suse.de \
    --cc=linux-cifs@vger.kernel.org \
    --cc=metze@samba.org \
    --cc=pc@cjr.nz \
    --cc=smfrench@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.