Re: CVS update: samba/source/include
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16 Jan 2003, Andrew Bartlett wrote: If you were going to start merging NTLMSSP changes across, then you need to add ntlmssp.h, otherwise this looks like you just missed it when merging includes.h/rpc_dce.h. I was going to merge those changes when I had them stable (not changing each night :-) I'm a little more lax with header files that with *.c cheers, jerry -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE+Jc9rIR7qMdg1EfYRAtNTAJ9b/jxjuhUj42XNqiRM9zggkTMsqACghVMR 5+e9lflFejnPYplaJzBJSc8= =wwMe -END PGP SIGNATURE-
3.0alpha21 performance degraded comparing to 2.2.5
I tested using the same hardware for windows client and the server, same setup and configuration. Network bandwidth was gigabits. I built both 2.2.5 and 3.0alpha21 from source. Here are my numbers for a single windows 2000 client, single samba server test. For reads, 2.2.5 gets 120 Mbps, while 3.0a21 gets only 80Mbps, which is a 33% decrease. Writing to samba, 3.0a21 gets a 15% decrease over 2.2.5. Samba performance is very important to us here. So please help me to make it better. Anybody know tricks to make samba 3.0alpha21 faster? Thanks in advance, Chere
Re: 3.0alpha21 performance degraded comparing to 2.2.5
On Wed, 15 Jan 2003, Chere Zhou wrote: I tested using the same hardware for windows client and the server, same setup and configuration. Network bandwidth was gigabits. I built both 2.2.5 and 3.0alpha21 from source. Here are my numbers for a single windows 2000 client, single samba server test. For reads, 2.2.5 gets 120 Mbps, while 3.0a21 gets only 80Mbps, which is a 33% decrease. Writing to samba, 3.0a21 gets a 15% decrease over 2.2.5. Samba performance is very important to us here. So please help me to make it better. Anybody know tricks to make samba 3.0alpha21 faster? Hmmm, I think we are going to need a little more info. 1. What were you using to test? 2. Is the problem a server-only problem, or is it in the combination? That is, if you use smbclient to push or pull files to/from Samba servers of the same versions as above, do you get the same results? 3. It might be good to see some network traces. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: CVS update: samba/source/utils
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16 Jan 2003, Andrew Bartlett wrote: The reason I didn't merge this on previous passes (yes, I've done merging too) is that I don't agree that this should be in 'net'. There isn't any logical connection for it to be here - it should probably be an option to pdbedit, or something like that. KO. At this stage in the game, little things like this are going to be the death of me. There is no reason for HEAD and SAMBA_3_0 to differ here. If you want to move it to another tool later, that's fine. But trying to keep track of little issues like this is too much work. Plus it's too hard to coordinate when tidbits of info are stored away in the mind of one developer. cheers, jerry -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE+JdNIIR7qMdg1EfYRAjpdAKC2H31A2661+e7olNM1fzX36yYpvwCdHyfP ylWk3glpJJdFyf8/c7A56m8= =AEbO -END PGP SIGNATURE-
Re: CVS update: samba/source/nsswitch
On 16 Jan 2003, Andrew Bartlett [EMAIL PROTECTED] wrote: Win2k has a bug (feature?) where there is a connection reset if there is a second connection from the SAME IP, before the first session-setup. So an unprivileged process on the client can cause a local denial of service just by repeatedly half-opening connections? Both races need to be protected be separate mutexes. The first should be protected in as generic a manner as possible, due to the fact that it is *any* connection from the IP. Can the connection function be called by a nonprivileged process (say rpcclient or smbclient) on the unix machine? Is so we either need to put the mutex somewhere world-writeable (gross) or just be willing to take our chances without it. -- Martin
Re: CVS update: samba/source/nsswitch
On Thu, Jan 16, 2003 at 12:50:57PM +1100, Martin Pool wrote: On 16 Jan 2003, Andrew Bartlett [EMAIL PROTECTED] wrote: Win2k has a bug (feature?) where there is a connection reset if there is a second connection from the SAME IP, before the first session-setup. So an unprivileged process on the client can cause a local denial of service just by repeatedly half-opening connections? Yes that's true. The same is true on a Windows box too. Jeremy.
Re: CVS update: samba/source/nsswitch
On Thu, Jan 16, 2003 at 12:50:57PM +1100, Martin Pool wrote: On 16 Jan 2003, Andrew Bartlett [EMAIL PROTECTED] wrote: Win2k has a bug (feature?) where there is a connection reset if there is a second connection from the SAME IP, before the first session-setup. So an unprivileged process on the client can cause a local denial of service just by repeatedly half-opening connections? Yes. Early versions of jCIFS did this, in fact. I was testing it at the CIFS conference one year and every time jCIFS reconnected the client would lose all of the smbclient connections that it had. Tridge kindly explained it to me. :) This behavior is actually written up in the SNIA doc and, I think, the Leach/Naik draft. Normally it doesn't impact Microsoft clients, but there is a hotfix for it, since it causes all sorts of trouble for clients on the far side of a NAT. Both races need to be protected be separate mutexes. The first should be protected in as generic a manner as possible, due to the fact that it is *any* connection from the IP. Can the connection function be called by a nonprivileged process (say rpcclient or smbclient) on the unix machine? Is so we either need to put the mutex somewhere world-writeable (gross) or just be willing to take our chances without it. There are several SMB clients out there now days. There's jCIFS, the FreeBSD SMB filesystem, and a few others. I don't think that there really is a fix for this problem. Not on the client side, anyway. Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
--with-cracklib for Samba
Hi all, Last night I did a grep -i todo in the source code, to see if I could contribute a little bit more ;-) I found the following: smbd/chgpasswd.c: /* TODO: Add cracklib support here */ I started working on this last night (using SAMBA_3_0 branch) and do have something working (the configure.in, documentation, etc is not done yet). I had to make my own API to cracklib to make this work because the original API uses getuid() and getpwuid() to get the username and fullname (gecos). I also found a lot of places in the cracklib code that is really not full-proof. So... in the search for a better solution: Tonight, I checked the cracklib included in npasswd. (I found a bug, it's also in the original cracklib!!!) There isn't a better API, still uses getuid()/getpwuid(). If the original cracklib or npasswd's cracklib is a good idea for Samba, I'll contact the maintainer for both products and see if they agree to update their code with the new API and also update their download site(s). I have the feeling cracklib original is quite dead unless there is a new maintainer (found nothing on sourceforge / freshmeat) and might have better chances with the cracklib included in npasswd. Besides using cracklib for password changing, I thought of the following idea. Once cracklib is enable, have an attribute in smb.conf force password change = yes. Then at logon if the password is found by cracklib, force the user to change their password right away. That's for Samba 3.0.1 ;-) unless I easily find how to do this! If you have other ideas let me know. Do I continue working on this or not? Best regards, Pierre B.
Patch for Samba 2.2.6 2.2.7 to work on OS X
In version 2.2.6 there was a change in util_sec.c that causes Samba to fail on OS X due to use of setregid(). Previously, Samba worked flawlessly on OS X. Apparently this is also a problem in other BSD-based operating systems, as this sparse bug report indicates in its headers: http://bugs.samba.org/cgi-bin/samba-bugs/incoming?id=26016 quote The function setregid() does not work correctly on our platform. The error message (log.smbd) is as follows: lib/util_sec.c:assert_gid(114) Failed to set gid privileges to (0,32766) now set to (32766,32766) uid = (0,0) lib/util.c:smb_panic(1094) PANIC: failed to set gid According to the man page (man setregid): This function did not work correctly, and its purpose is now better served by the use of the setegid() function. /quote The problem reported is identical to the one I am having on OS X (unable to browse or do anything requiring privs). There is a patch included in the report that fixes the problem on OS X 10.2.3. I have also tested it (successfully!) to make sure it doesn't break anything on Linux with Slackware 8.1 (upgraded to 2.4.20). So... comments? Does the patch Do The Right Thing? Think this patch or something similar could get merged sometime? :) Michael Bennett [EMAIL PROTECTED]
Re: Patch for Samba 2.2.6 2.2.7 to work on OS X
On Thu, Jan 16, 2003 at 01:07:34AM -0500, Michael Bennett wrote: So... comments? Does the patch Do The Right Thing? Think this patch or something similar could get merged sometime? :) I remember looking at this patch. The problem is it does something like : #ifdef *BSD.. new code... #else original code. #endif We don't accept patches that are specific to a particular OS in this way anymore (unless there's a really good reason). The correct way to do this is to add a feature test in configure.in that checks if this function works correctly, that way it gets fixed for all platforms it is broken on. A patch like that would get accepted immediately. Without it, we have to write the feature test. Jeremy.
Re: --with-cracklib for Samba
Pierre, Sounds interesting. Please keep this going as there is a lot of interest in forced secure password change process. Strongly suggest getting the official sources updated, as you have already suggested. There should be someone who might want to help get this into the official code tree. Who knows, might even spawn a security update cycle. - John T. On Wed, 15 Jan 2003, Pierre Belanger wrote: Hi all, Last night I did a grep -i todo in the source code, to see if I could contribute a little bit more ;-) I found the following: smbd/chgpasswd.c: /* TODO: Add cracklib support here */ I started working on this last night (using SAMBA_3_0 branch) and do have something working (the configure.in, documentation, etc is not done yet). I had to make my own API to cracklib to make this work because the original API uses getuid() and getpwuid() to get the username and fullname (gecos). I also found a lot of places in the cracklib code that is really not full-proof. So... in the search for a better solution: Tonight, I checked the cracklib included in npasswd. (I found a bug, it's also in the original cracklib!!!) There isn't a better API, still uses getuid()/getpwuid(). If the original cracklib or npasswd's cracklib is a good idea for Samba, I'll contact the maintainer for both products and see if they agree to update their code with the new API and also update their download site(s). I have the feeling cracklib original is quite dead unless there is a new maintainer (found nothing on sourceforge / freshmeat) and might have better chances with the cracklib included in npasswd. Besides using cracklib for password changing, I thought of the following idea. Once cracklib is enable, have an attribute in smb.conf force password change = yes. Then at logon if the password is found by cracklib, force the user to change their password right away. That's for Samba 3.0.1 ;-) unless I easily find how to do this! If you have other ideas let me know. Do I continue working on this or not? Best regards, Pierre B. -- John H Terpstra Email: [EMAIL PROTECTED]
