Re: Roadmap to 3.0

2002-09-24 Thread abartlet

On Wed, Sep 25, 2002 at 07:45:36AM +0200, Eddie Lania wrote:
 Loadable RPC implementations yes o o o
 
 Does this mean that it will support KIXTART as well?

I've yet to see a good definition of what KIXTART needs, so I
can't say if we will support it.

Andrew Bartlett



Re: strupper() on username and domain in cli_session_setup_nt1()?

2002-09-23 Thread abartlet


On Mon, Sep 23, 2002 at 08:30:28AM -0500, Gerald Carter wrote:
 On Mon, 23 Sep 2002, Tim Potter wrote:
 
  I'm just wondering whether it is strictly necessary to uppercase the
  username and domain name when performing a session setup.  Applying the
  following patch should not break anything and would make smbclient be
  able to test for case sensitivity bugs in the remote server.
  
  The behaviour of uppercasing everything seems to be peculiar to Windows
  9x.  According to some testing done by the HP guys and girls, NT and
  2000 send across the case of the username as it was created in the SAM,
  whereas XP sends the case the user logged in with.
 
 The patch looks fine to me Tim.  

Makes sense to me - particularly when the remote server is a samba box
with an InterCase username.

Andrew Bartlett



Re: approaching release of 3.0alpha20

2002-09-23 Thread abartlet

On Mon, Sep 23, 2002 at 10:01:53AM -0500, Gerald Carter wrote:
 Everyone,
 
 I would like to do another alpha snapshot release of the 3.0
 code base later this week.  Does anyone know of any code that 
 is too unstable for a release (seg faults, etc...)?  

Apparently we ignore non-primary groups (which, given recent changes
I can certainly beleive), but I've not had a chance to chase it
up.

Andrew Bartlett



Re: Samba 3.0a19 breaks winbind helpers?

2002-09-10 Thread abartlet

On Tue, Sep 10, 2002 at 11:37:38AM +0200, Chemolli Francesco (USI) wrote:
  This program is intended to be invoked directly by external 
  programs, so
  they can pass in the string directly into the right argv 
  buffer.  Shell
  users can quote.
  
   What about a also supporting a stream oriented NTLM mode?
  
  I don't see the need - most applications doing this so frequently that
  they need a stream mode are doing NTLMSSP anyway.  Less interfaces
  again...
 
 I think a stream interface is needed for performance reasons.

Why?  We have NTLMSSP as a stream - and if I don't currently see any 
application for raw NTLM outside the MSCHAPv2 example - which 
probalby would not benifit anyway...

I think the performance issues here are overrated.

Andrew Bartlett



Re: initial gencache implementation

2002-09-05 Thread abartlet

On Fri, Sep 06, 2002 at 10:17:19AM +1000, Tim Potter wrote:
 On Thu, Sep 05, 2002 at 12:15:36PM +0200, Rafal Szczesniak wrote:
 
  This is first implementation of caching mechanism. It includes
  both lib/gencache.c code and utils/net_cache.c as command-line
  control/testing tool.
  
  comments are welcome
 
 Rafal, that looks pretty good.  Since you ask, I do have a few comments.
 (-:
 
 You assume that any cached data will be in null terminated string format
 which is not always the case.  

I understand this is a design property - it's up to the caller to mess with
structs etc.  This keeps the cache simple, and allows for human inspection
with 'net cache' etc.

 This is just my personal opinion but I would prefer for gencache_set to
 crash if you pass it a NULL pointer for the key or value parameter.
 Returning false in this case only hides the error until further along 
 in the execution path by which time it will be more difficult to track 
 down the original error.

Agreed.

Andrew Bartlett



Re: samba internals and application development advice

2002-08-21 Thread abartlet

On Wed, Aug 21, 2002 at 06:31:57PM -0400, Sean Finney wrote:
 hi all--
 
 i've been ghosting this list for a few months now, hoping that i might
 read an answer to my question without having to step up and ask, but
 now i'm guessing that this won't be the case, so here goes...
 
 i'd like to write an application in C that does something along the
 lines of crawling a local area network, finding smb sharing computers
 and enumerating shares.  

See smbtree, in most recent Samba versions.

Andrew Bartlett




Re: Thanks for fixing oplock.c for Linux 2.0 in 2_2 CVS

2002-05-29 Thread abartlet

On Wed, May 29, 2002 at 04:43:05PM -0700, Jeremy Allison wrote:
 On Thu, May 30, 2002 at 08:10:22AM +1000, Andrew Bartlett wrote:
  
  Isn't there a way we can 'idle' the connection by tearing down the
  protocol?  Actually issuing a 'you are idle, shutting down' to the
  client?  
 
 Nope - would require a client change I'm afraid. There's nothing
 in the protocol to allow this.

What about at the NetBIOS level?  I'm wondering how somthing like NetBEUI 
(being just raw netbios on ethernet effectivly) closes connections.

And are you saying that Win2k will never 'idle' a client connection?  I'm
sure I've seen smbfs being 'idled' by NT before...

Andrew Bartlett




Re: [PATCH] store SID's in SAM_ACCOUNT

2002-05-28 Thread abartlet

On Tue, May 28, 2002 at 02:07:52PM +0200, Simo Sorce wrote:
 Hi Stefan.
 
 As you may have seen I have already changed the pdb_interface to search
 by SID and I'm really i favour to use SIDs inside SAM_ACCOUNT instead of
 RIDS, but I think this patch does not address the problem the right way.
 
 What we should do is store the SID in the backends, not convert it at
 run time.

Given time, yes.  But (for example) we really cannot change the LDAP schema
at this stage (we must certainly still support the current schema) and other
backends might chose to store the RID/SID in a way that best suits their
technology.

 I think we may use part of your code inside pdbedit to have a tool to
 upgrade from previous backends that store by RID into the new ones.

I don't see the need for a forced 'upgrade'.  New backends can use this - but
with the majoir passdb backends (ldap, smbpasswd) still being RID based into
the future, we are going to still need this.

 I'm working on tdbsam2 that will store by SID and have also some other
 interesting things (privileges and such) I have discussed with JFM the
 last samba experience conference.

BTW, pdbedit already handles 'upgrades', just import from one format and 
export to the other.  This code will ensure that it all 'just works'

 What others do think?

I think this patch is fine.  We have to start somewhere - and while you 
might *like* to rework the while passdb in one hit, I don't see any reason
why an incremental patch cannot be applied in the meantime.

On the patch itself, my only comment is that when implementing the
compatibilty functions, make them call the 'real' funcitons (see 
pdb_set_plaintext_password()) rather than modifiying the struct directly.

Also I see you still have pdb_set_user_rid(), which just calls the fallback.
If this is really a complete patch, then these functions can go, and other
coders will notice it - and hopfully see what the new interface is.

Either that, or don't rename the fn at all.

Finally, re the SID initialisation:  Make a new function that returns the 
global sam sid.  Make it 'auto-initailise', if its not been run before, then
it should figure it out, and store it in a static.

Andrew Bartlett




Re: Proposed code cleanup

2002-05-23 Thread abartlet

On Fri, May 24, 2002 at 11:27:39AM +1000, Tim Potter wrote:
 On Fri, May 24, 2002 at 11:17:59AM +1000, Andrew Bartlett wrote:
 
   Anyway - that looks like a good patch.  I've been dying to get rid of all 
   those silly make_nmb_name() calls everywhere but was not brave enough.
  
  I'll proabably add a cli_pipe_connection() function (feel free to suggest 
  a better name) that just calls cli_full_connection, but with IPC$ implicit
  and instead specifying the pipe to setup.
  
  How does that sound?
 
 Sounds good to me.
 
 One point - is there any reason to pass around the password and the
 length of the password to cli_full_connection()?

Not really.  Just habit - it is always a null terminated ASCII (or utf8 
actually) password.  (and everyobdy is just doing strlen for that param
anyway...)

I'll kill it.

Andrew Bartlett












Re: winbindd uid and gid range assumptions

2002-05-14 Thread abartlet

On Tue, May 14, 2002 at 08:20:03AM -0400, Mike Gerdts wrote:
 On Mon, 2002-05-13 at 18:42, Andrew Bartlett wrote:
  Moving over the socket is a very expencive operation, particularly
  compared to a simple if statement.  Also, where we know that a uid is
  local, we need to check with code that winbind isn't linked to - the
  passdb backend.
 
 So in a situation where you have UIDs interspersed between NIS and
 domain users, it may be cheaper to check to see if it is local first
 followed by winbind.  At least this may be better in my situation, as
 each of my NFS/Samba servers is already an NIS slave.  Even though a UID
 lookup may have to talk to nscd and/or ypserv, it is still on the same
 machine, thus avoiding network delays.
 
 Perhaps this would be a place where the plug-in architecture could be
 useful as well.  Checks could all be relegated to idmap_ops-islocal(). 
 The default op could be to check the winbind id range.  Others that are
 willing to or need to pay the price of a socket operation will have the
 option of doing so.  Presumably islocal() would not just be a straight
 BOOL operation.  I could imagine it replying True, False, LocalFirst, or
 DomainFirst.

Sounds like an interesting idea.

  But yes, we need to deal with things like getting the uid from the SFU
  LDAP schema, so this may well change in the future. 
 
 Do you have any relative time frame or rough release number that you are
 shooting for? 

No, its just an idea in my HEAD until I get a chance to look at it, or sombody
codes me up a patch :-).

 Do you see a plug-in that merges the functionality of the existing idmap
 to the architecture present in the VFS, or should I start barking up a
 different tree?

That seems to be the current plugin arch, but we may move across to a more
centralised scheme at some stage.

Andrew Bartlett




Re: [Samba] Impending Removal of --with-ssl

2002-05-05 Thread abartlet

On Sun, May 05, 2002 at 10:06:53AM -0400, Nathan Lutchansky wrote:
 On Sun, May 05, 2002 at 02:50:13AM -0700, [EMAIL PROTECTED] wrote:
  On Sat, May 04, 2002 at 11:22:41PM -0400, Nathan Lutchansky wrote:
   
   1) Can we assume that Microsoft will never include SSL functionality in
  their Windows clients?  Does MS have some other method of providing
  transport security instead?  If the answers are yes and yes, then 
  I'd say it is safe to remove.  Otherwise it might feel silly to add SSL 
  back when some XP service pack adds SSL functionality later on.
  
  yes on both counts.  Message authenticaion and encryption are available in the 
  CIFS protocol, and are detailed in the SNIA Technical Reference (not to
  be confused with the MS Technical Reference)
 
 Oh.  Well, that sounds like the way to go in the future.  I hope it is not 
 as ugly to implement as SSL.
 
   2) I'd started a project to authenticate users SMB clients based on client
  SSL certificates.  If --with-ssl is removed, SSL authentication can 
  still be done with wrappers and LIBSMB_PROG, but the server wrapper 
  would somehow need to pass authentication information to Samba.  The
  easiest way is to setreuid to the target user before execing smbd, but
  can smbd handle this?  What happens if smbd is started (without -D) as
  some user other than root?  -Nathan
  
  Samba expects this, and allows become_user() calls to 'fail' but still 
  requires passwords as before.  You could write a new authentication module
  that implments your requirements quite trivially.  (And use environment 
  variables or the like to pass the state info along).
 
 OK, I'll look into this when I have time to get back to that project.  
 Thanks for the hint.

While samba will 'cope' with non-root setups, this really only works in
testing environments, where that same user owns the critical files.

As such I would suggest you make your SSL wrapper leave smbd as root,
and make a cusome authenticaion module figure it out from there.

See samba's rhosts support module for a trivila example of what 
you want to do. (It only still exists becouse its a good example, not
becouse anybody should use it...)

Andrew Bartlett




Re: wbinfo -t and Win2K DCs ...

2002-05-03 Thread abartlet

On Fri, May 03, 2002 at 09:38:33AM +0930, Richard Sharpe wrote:
 Hi,
 
 I have run into a spot of bother with wbinfo and Win2K.
 
 We run Samba as a member server from a Win2K DC.
 
 We join the DC correctly, but wbinfo -t does not work.

Then you have not joined the domain corrrectly...

 This seems to be because the WINS server running on the Win2K DC will not 
 answer queries looking for DOMAIN#1c.
 
 However, I know we have joined because wbinfo -u works.

Is this in Samba 2.2 or 3.0?  wbinfo -u works without a correct domain join
in 2.2 - becouse the operations are done anonymously.

 Has anyone seen this? Is there a solution on the DC, or do I have to hack 
 winbindd to be able to look up the DC correctly?

I think you have not joined the domain correctly - it can't be wins if
wbinfo -u is working.

Andrew Bartlett




Re: copying 2Gb files

2002-05-03 Thread abartlet

On Fri, May 03, 2002 at 09:54:44AM +0100, Mike Pigott wrote:
 Hello,
 
 We are running Samba 2.0.7 for IRIX (v6.5.11m) and are receiving the error cannot 
copy file * parameter is incorrect when attempting to copy files  2Gb.  OS is 
Win98.  Can you confirm if this is a known bug, or shall I triple check the code of 
the developer who is attempting to copy this data with his utility?
 

Large file support really only grew to maturity in the 2.2 series - I would
suggest an upgrade.

Andrew Bartlett




Impending Removal of --with-ssl

2002-05-03 Thread abartlet

This message is a warning: 

--with-ssl will die.

Ok, thats enough with the dramatics, but the general consensus amoungst the 
samba team is that --with-ssl really isn't a particulary smart idea, and 
it is better implmented by external tools.

So what is --with-ssl exactly?  And why kill it?

--with-ssl allows Samba to tunnel SMB inside an SSL connection.  Unfortunetly
there are only 2 clients:  smbclient and sharity.  Windows clients simply
don't know how to use SSL.

So why kill it?  It might be useful to sombody?

While some small minority of users might find it handy, it confuses many more,
including a supprising number of our distributors.  Users actually using this
functionality will find that they can achive almost the same effect by creative
use of 'stunnel' both as an inetd wrapper as as a 'LIBSMB_PROG' program.

Finally, it is intrusive and ugly, with large #ifdef sections in what should
be simple code.

If sombody can come up with both reasons to keep this code, and time to 
maintain it, then I would like to hear it.

Andrew Bartlett




Re: overriding dyn_CONFIGFILE in pdbedit with command line parameter

2002-04-29 Thread abartlet

On Mon, Apr 29, 2002 at 05:00:32PM -0400, Bradley W. Langhorst wrote:
 
 I decided to modify pdbedit to handle another 
 command line parameter -c /pathto/smb.conf
 
 I've got that working - but I'm not sure it's safe
 Is it reasonable to expect the popt stuff to give me back 
 null terminated string?

Can you resend as a diff -u?

As to null termination, I think that is safe.

Andrew Bartlett




Re: Re: User Manager for Domains / RAS callback problem

2002-04-27 Thread abartlet

On Fri, Apr 26, 2002 at 10:35:41AM +0200, Jean Francois Micouleau wrote:
 
 
 On Thu, 25 Apr 2002, Alex Keahan wrote:
 
  For the time being, I am going to implement a temporary solution, but
  I would really like to see this fixed in the 2.2 branch.
 
 it won't be fixed in 2.2, it's way too complex.
 
  Can the callback info be easily added to the mix without pulling in the
  whole nine yards?   If yes, what are the missing RPC calls that I should
  implement, and where do you think the extra info should go -- the
  smbpasswd file?   What is the approach taken by the 3.0 / TNG branches?
 
 that's not only implementing some missing rpc calls, that's also changing
 the /etc/smbpasswd file format to store the callback number.

This is where LDAP shines.  I think we already store the callback number
but there may be other RPCs required.

I like the way we can easily extend the LDAP stuff - much better than 
smbpasswd/tdbsam in this respect.

Andrew Bartlett