smbfs AD support (was Re: CIFS VFS posted)

[Andrew Bartlett]

Urban Widmark wrote:
> 
> On Fri, 21 Jun 2002, Andrew Bartlett wrote:
> 
> > Silly mapping bug?  NTSTATUS -> dos stuff?
> 
> No, NTSTATUS -> linux errno value. The patch makes smbfs use NTSTATUS
> codes and maps dos -> NTSTATUS for old systems.

Most of our error mapping is pretty dodgy - but the NTSTATUS -> dos
error map is quite good (extracted from NT over the wire) - you might
want to consider doing it the other way around.

But given the small number of posix errors, this probably isn't worth
it.

> > As to smbmount, would you like the 'negotiate' patches put into Samba
> > HEAD?  I'm *very* interested in the kerberos stuff, particularly with
> > Samba unix extenstions.
> 
> Attached. It will mount with that if you have a kerberos ticket and
> specify the 'krb' option, but you will get the wrong error codes in smbfs
> and some things will stop working. This patch helps, but has bugs:
> 
> http://www.hojdpunkten.ac.se/054/samba/smbfs-2.4.19-pre5-error32.patch
> 
> The error code numbers are spread out so I used separate arrays to make
> them more compact. But I think I just made it complicated, and the bug
> being in that part proves that I made a mess of it.
> 
> I have some other stuff I should have gotten into samba 2.2 long ago, most
> of that wants to be in HEAD too. I'm going to add this together with that,
> once I get everything cleaned up.
> 
> > Possibly becouse Samba client code is *ugly* :-).
> 
> Is it beyond repair?

No, but it is too focussed on a single tree connect, of a single user. 
This doesn't matter for smbfs, because those attributes don't matter
once smbfs gets the fd and can chew on it from there, but it does limit
it on the samba side.

> And fixing the samba client code also helps smbclient and smbwrapper, as
> well as any external libsmb users. Or?

Yes, it would - but there is a fair bit of 'history' in that code to
overcome.

> If there wasn't a performance loss (which I believe it is), a cool thing
> would be to make smbfs a userspace filesystem re-using the libsmb code
> directly. Others have suggested this, but not done much about it.
> 
> > The idea there is just like smbmount - the syntax comes from a desire to
> > be a bit like NT, and an attempt to get just one client utility -
> > instead of a small gaggle of little, undocumented utilities.
> 
> But having a command for mounting like NT is just bad. _Please_ don't.
> 
> People want to put filesystems in /etc/fstab[1], in autofs maps and unless
> there is a good reason to be different the way to do things is to use
> mount as the interface.
> 
> To reduce confusion it should be the only interface and it should work
> exactly like mount always does. This is what people expect from a
> filesystem and smbfs and ncpfs are the ugly ducklings in the linux kernel
> for not being like the others.
> 
> 'net use' can be a frontend to mount that does absolutely nothing except
> rearrange the options. Well, the user could do that themselves so it seems
> rather pointless to me.

I can certainly see your point here.

> Or it is a command that does some work before passing them to mount, eg
> name lookups. If you do that you get something that doesn't work equally
> from fstab.
> 
> The old smbmount/smbclient syntax was, er ... interesting?
> 
> The current smbmount makes it work with mount, but some things break such
> as user mounts with noexec/nosuid flags. smbmount is not a model to copy.
> Adding fstab parsing to fix these issues will bring down the wrath of
> Tridge :) and he is right because you shouldn't duplicate that work.
> 
> This could perhaps be fixed by improving mount <-> mount.smbfs
> communication, but better by replacing smbmount with smbconnect
> ("net connect").
> 
> smbconnect is just smbmount without the mounting and daemon code. It
> patches mount to get the "Password:" prompt for people that needs that and
> to not write passwords from the commandline into /etc/mtab. It patches
> smbfs to make it call a userspace program for its connections.
> 
> http://www.hojdpunkten.ac.se/054/samba/smbconnect/
> 
> But a 'net connect' that connects and places that connection somewhere
> (ioctl, /dev, /proc ...) would work just as well. The only request from
> the smbfs side is to have some control over which capabilities are sent in
> the negotiation.
> (eg. smbfs knows if it supports large files, libsmb does not.)
> 
> For future DFS support smbconnect allows the dfs directories to be mounted
> as new mounts, without having to keep the connection code in the kernel.

That certainly looks like the best way to do it.  Parse the DFS in
kernel, and call back to userspace to do the legwork.

> /Urban
> 
> [1] - Just search the samba list for people that do that, and the trouble
>       they run into when it only sort of works.
>       If you want to upset the autofs maintainer, ask him about samba
>       1.9.x/2.0.[01234] mount syntax :)

Knowing some of the samba code I've come across in my time on the team,
I can certainly imagine...

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net