Re: interesting fact about StrCaseCmp
On Tue, Feb 18, 2003 at 06:23:41PM +1100, Martin Pool wrote: > One little malloc() could hardly make it any worse, although I will do > a test tomorrow to check. "One little malloc()" - I'll remind you of that quote later :-). But please do the test, that's the only way we can really be sure if it's a speedup or not. Jeremy.
XP can't enumerate user info.
Hi all, I have installed Samba 3.0 alpha 21 on my FreeBSD for a long time. I enable ACL and it works fine when I connect from Win2k client. I can add and delete acl entry. Recently, I use WinXP to connect to my server. When I try to add new ACL entry, I get a popup message to ask username/password pair. After I type it, I get nothing. No server user and group list on text box, only those default entries. I use Ethereal to get some packets and find that WinXP doesn't send any samr request to my server. Why? Best regards, Vic Hsu [EMAIL PROTECTED] 886-2-25521814 ext. 827 Synology Inc.
Re: ideas for optimizations with large groups
I've just compiled the CVS version of 2.2.x and it seems to have fixed the
problem. I'd been merrily patching each new version of Samba as it came out
;-)
Thanks,
Chris
On Tue, 18 Feb 2003 06:10:42 + [EMAIL PROTECTED] wrote:
> On Wed, Mar 06, 2002 at 11:24:23AM +, Chris Wakelin wrote:
> > We had big problems with an upgrade to Samba 2.2.3a on Solaris 8 due
> > to this groups change. Samba 2.2.2 was fine, but had occassional
> > oplock problems (hence the desire to upgrade). We have a large number
> > (~1000) of (sometimes large) NIS groups.
> >
> > I've patched our version of Samba 2.2.3a in lib/util_getent.c
> > get_users_in_group() commenting out the line :-
> >
> > if (strchr(gname,*lp_winbind_separator())) {
> >
> > (and the lines following the "if" statement) so that the old
> > getgrnam() calls are used instead (as they are for winbindd).
> >
> > This fixes the problem for us, but I'd like strongly to support
> > David's suggestion that the change to using getgrent() be made a
> > compile-time option for Tru64 only.
>
> It took some time, but I finally got to this, sorry :-).
>
> Jeremy.
--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+--
Christopher Wakelin,[EMAIL PROTECTED]
IT Services Centre, The University of Reading, Tel: +44 (0)118 378 6630
Whiteknights, Reading, RG6 2AF, UK Fax: +44 (0)118 975 3094
Printing DBs by service name, not printer name
I'm wondering, why are our printing databases (for things like the print queue) indexed by service name, rather than printer name? Doesn't this mean we will get 'weird stuff' happening if we have two names for a printer? I'm getting some very weird behavior where printer name is based on %m, with some uninitialized data being output back the the client. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
Re: interesting fact about StrCaseCmp
Look at other parts in the code, a nice idea is to compare character by
character until the string is an ASCII one, as soon as we detect a non
ascii character we revert to the standard method and re-compare the
strings, Tridge has gained very good optimizations with this twchnique.
Simo.
On Tue, 2003-02-18 at 01:35, Martin Pool wrote:
> On 18 Feb 2003, Andrew Bartlett <[EMAIL PROTECTED]> wrote:
>
> > Possibly only for long strings? But then that is probably
> > micro-optimization.
>
> If we really cared about optimizing this function, then we would
> compare character-by-character rather than converting both strings to
> uppercase first. This is a bit hard for some wierd encodings I know,
> but it ought to be possible to do it in charcnv.c.
>
> The case where we compare, for example, a thousand-character string to
> the empty string is ridiculously slow at the moment.
>
> I don't know if this is a problem for Samba overall or not, so I'm not
> touching it at the moment.
>
> int StrCaseCmp(const char *s, const char *t)
> {
> pstring buf1, buf2;
> unix_strupper(s, strlen(s)+1, buf1, sizeof(buf1));
> unix_strupper(t, strlen(t)+1, buf2, sizeof(buf2));
> return strcmp(buf1,buf2);
> }
--
Simo Sorce - [EMAIL PROTECTED]
Xsec s.r.l.
via Durando 10 Ed. G - 20158 - Milano
tel. +39 02 2399 7130 - fax: +39 02 700 442 399
signature.asc
Description: This is a digitally signed message part
W2K, krb5 and samba-3.0alpha21
Hi,
I run a MIT KRB5 KDC and succesfully can authenticate my W2K Clients
and users against the KDC. User- and machine-data are stored in a
OpenLDAP directory server, but no passwords, as I want to make use of
Kerberos. Although I compiled samba-3.0alpha21 --with-krb5 created
a cifs/machine.domain principal and added a realm directive to
smb.conf , samba still does not obtain a ticket and therefore can't
login to my workgroup and my shares. Howe can I make samba MIT KRB5 aware and beeing
able to obtain TGT's ?
Following an excerpt from my krb5kdc log
-.-.-.-..-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
TGS_REQ (7 etypes {23 -133 -128 3 1 24 -135}) 192.168.100.31(88): ISSUE: authtime
1044633988, etypes {rep=1 tkt=16 ses=1}, [EMAIL PROTECTED] for [EMAIL PROTECTED]
Feb 07 17:06:46 marin krb5kdc[999](info): AS_REQ (7 etypes {23 -133 -128 3 1 24 -135})
192.168.100.31(88): ISSUE: authtime 1044634006, etypes {rep=3 tkt=16 ses=1},
[EMAIL PROTECTED] for [EMAIL PROTECTED]
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
host/cyan.l4b.de is my W2K workstation.
-Dieter
--
Dieter Kluenter | Systemberatung
Tel:040.64861967 | Fax: 040.64891521
mailto: [EMAIL PROTECTED]
http://www.schevolution.com/tour
Patches for winbindd over TCP and a "failover port" option
Our product uses Samba as a component. In our product we were forced to modify certain parts of Samba, namely: Winbindd running over TCP (to a remote host) Smbd listening to an additional "failover" port. Allow listening on non-broadcast interfaces. All these changes are very minimal. In order to comply with the GPL and provide the community with what little code we've modified, attached is the patch file between this version and Samba 3.0a20. I'm afraid we've never merged it with later versions, since they never seemed to work. I sincerely hope this helps people, Regards, Nir. -- Nir Soffer -=- Software Engineer, Exanet Inc. -=- "The poor little kittens; They lost their mittens; And now you all must die. Mew, Mew, Mew, Mew, And now you all must die." www.sluggy.com, 24/10/02
Re: Patches for winbindd over TCP and a "failover port" option
hi, On Tue, Feb 18, 2003 at 05:57:55PM +0200, Nir Soffer wrote: > Our product uses Samba as a component. In our product we were forced to > modify certain parts of Samba, namely: > > Winbindd running over TCP (to a remote host) this sounds very interesting. > Smbd listening to an additional "failover" port. > Allow listening on non-broadcast interfaces. > > All these changes are very minimal. In order to comply with the GPL and > provide the community with what little code we've modified, attached is > the patch file between this version and Samba 3.0a20. you have forgotten to add that patchfile :) thanks, guenther -- Guenther Deschner [EMAIL PROTECTED] SuSE Linux AGGnuPG: 8EE11688 Berliner Str. 27 phone: +49 (0) 30 / 430944778 D-13507 Berlin fax: +49 (0) 30 / 43732804 msg06182/pgp0.pgp Description: PGP signature
Re: Patches for winbindd over TCP and a "failover port" option
On Tue, 18 Feb 2003, Guenther Deschner wrote: > you have forgotten to add that patchfile :) Note that since last month the Samba listserver has started filtering message attachments: http://lists.samba.org/pipermail/samba-technical/2003-January/041954.html Inline your patches in the message body, or make sure that your mail program flags them as content-type text/plain. Regards, -- Neil Hoggarth Departmental Computer Officer <[EMAIL PROTECTED]> Laboratory of Physiology http://www.physiol.ox.ac.uk/~njh/ University of Oxford, UK
REPOST: Patches for winbindd over TCP and a "failover port" option
Very well then - but this might seriously screw up wrapping:
Our product uses Samba as a component. In our product we were forced to modify certain
parts of Samba, namely:
Winbindd running over TCP (to a remote host)
Smbd listening to an additional "failover" port.
Allow listening on non-broadcast interfaces.
All these changes are very minimal.
In order to comply with the GPL and provide the community with what little code we've
modified, attached is the patch file between this version and Samba 3.0a20. I'm afraid
we've never merged it with later versions, since they never seemed to work.
There may be some other changes thrown here and there, they may or may not work.
Naturally, the usual disclaimer applies - I don't gurantee this code will work. It
might even burn your computer. Use at your own risk.
I sincerely hope this helps people,
Regards,
Nir.
=== patch ===
diff -r -u /users4/nirs/tmp/samba-3.0alpha20/source/configure.developer
./configure.developer
--- /users4/nirs/tmp/samba-3.0alpha20/source/configure.developerTue Sep 25
07:08:05 2001
+++ ./configure.developer Mon Jan 6 20:39:03 2003
@@ -1,2 +1,3 @@
#!/bin/sh
+export CFLAGS="-DWITH_FO_PORT -DWITH_WINBIND_CFG"
`dirname $0`/configure --enable-developer $*
Only in ./: configure.exanet
diff -r -u /users4/nirs/tmp/samba-3.0alpha20/source/install-sh ./install-sh
--- /users4/nirs/tmp/samba-3.0alpha20/source/install-sh Wed Jul 29 06:06:48 1998
+++ ./install-shThu Feb 28 17:25:58 2002
@@ -184,7 +184,7 @@
if [ x"$chowncmd" != x ]; then $doit $chowncmd $dst; else true ; fi &&
if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dst; else true ; fi &&
if [ x"$stripcmd" != x ]; then $doit $stripcmd $dst; else true ; fi &&
- if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dst; else true ; fi
+ if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dst; true; else true ; fi
else
# If we're going to rename the final executable, determine the name now.
diff -r -u /users4/nirs/tmp/samba-3.0alpha20/source/lib/interface.c ./lib/interface.c
--- /users4/nirs/tmp/samba-3.0alpha20/source/lib/interface.cMon Jul 15 18:10:42
2002
+++ ./lib/interface.c Mon Jan 6 20:31:29 2003
@@ -61,8 +61,8 @@
}
if (ip_equal(nmask, allones_ip)) {
- DEBUG(3,("not adding non-broadcast interface %s\n",inet_ntoa(ip)));
- return;
+ DEBUG(3,("adding non-broadcast interface %s\n",inet_ntoa(ip)));
+ //return;
}
iface = (struct interface *)malloc(sizeof(*iface));
diff -r -u /users4/nirs/tmp/samba-3.0alpha20/source/nsswitch/wb_common.c
./nsswitch/wb_common.c
--- /users4/nirs/tmp/samba-3.0alpha20/source/nsswitch/wb_common.c Thu Sep 26
22:38:34 2002
+++ ./nsswitch/wb_common.c Mon Jan 6 20:39:03 2003
@@ -27,6 +27,15 @@
#include "winbind_nss_config.h"
#include "winbindd_nss.h"
+#ifdef WITH_WINBIND_CFG
+#include
+#include
+#include
+#include
+
+#define WINBIND_CFG "/etc/winbind.cfg"
+#endif /* WITH_WINBIND_CFG */
+
/* Global variables. These are effectively the client state information */
int winbindd_fd = -1; /* fd for winbindd socket */
@@ -146,6 +155,60 @@
/* Connect to winbindd socket */
+#ifdef WITH_WINBIND_CFG
+int winbind_open_tcp_sock(int tcpport, char *ip)
+{
+struct sockaddr_in servaddr;
+
+if (winbindd_fd != -1) {
+return winbindd_fd;
+}
+
+bzero(&servaddr, sizeof(servaddr));
+servaddr.sin_port = htons(tcpport);
+servaddr.sin_family = AF_INET;
+
+if ((winbindd_fd = socket(AF_INET, SOCK_STREAM, 0)) == -1) {
+ perror("socket");
+return -1;
+ }
+
+inet_pton(AF_INET, ip, &servaddr.sin_addr);
+free(ip);
+
+if (connect (winbindd_fd, (struct sockaddr *) &servaddr, sizeof(servaddr)) !=0 ) {
+close_sock();
+return -1;
+}
+
+ /* Return socket */
+ return winbindd_fd;
+}
+
+int read_wb_config(int *portnum, char **ip)
+{
+int fd;
+int port;
+char s[300];
+char p[50];
+
+
+if ((fd = open(WINBIND_CFG, O_RDONLY)) < 0)
+ return 0;
+
+read(fd, s, 300);
+
+sscanf(s, "%s %d", p, &port);
+
+*portnum = port;
+
+*ip = malloc(strlen(p) + 1);
+strcpy(*ip, p);
+
+return 1;
+}
+#endif /* (ifdef WITH_WINBIND_CFG) */
+
int winbind_open_pipe_sock(void)
{
#ifdef HAVE_UNIXSOCKET
@@ -232,15 +295,23 @@
int write_sock(void *buffer, int count)
{
int result, nwritten;
-
+ int portnum;
+ char *ip;
+
/* Open connection to winbind daemon */
- restart:
+restart:
+#ifdef WITH_WINBIND_CFG
+ if (read_wb_config(&portnum, &ip)) {
+ if (winbind_open_tcp_sock(portnum, ip) == -1 ) {
+ return -1;
+ }
+ } else
+#endif /* WITH_WINBIND_CFG */
if (winbind_open_pipe_sock() == -1) {
return -
Re: Patches for winbindd over TCP and a "failover port" option
On Tue, 18 Feb 2003, Guenther Deschner wrote: > hi, > > On Tue, Feb 18, 2003 at 05:57:55PM +0200, Nir Soffer wrote: > > Our product uses Samba as a component. In our product we were forced to > > modify certain parts of Samba, namely: > > > > Winbindd running over TCP (to a remote host) This, of course, can be dangerous unless your internal network is totally separate from the outside world. I would imagine that it is in the configuration that you guys are using. Looks like Exanet is about ready to release a product :-) > this sounds very interesting. > > > Smbd listening to an additional "failover" port. > > Allow listening on non-broadcast interfaces. > > > > All these changes are very minimal. In order to comply with the GPL and > > provide the community with what little code we've modified, attached is > > the patch file between this version and Samba 3.0a20. > > you have forgotten to add that patchfile :) > > thanks, > guenther > > -- Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
password quality script - pre-release
Hi,
I first want to thank *everyone* who participated in the previous
thread and when needed, took the time to add their valuable
comments.
I attached "password-quality.c" (it's just this part) -- I hope I
got this right -- if not let me know what to change and I'll do it.
At the end of the file, there are functions that could be move
in other files (.../source/lib/???). If you want to move anything,
let me know what to move and the "destination" file.
For the next few days, here's my TODO list prior to post a
"release candidate" patch:
- documentation: update smb.5.sgml
- Doxygen comments
- finish the simple external script I started (add change uid/gid code)
- change DEBUG() code to appropriate log level
- apply changes from your comments
- create a patch againts HEAD (it's a start!). I'll do the 2_2 / 3_0
once it's in HEAD, well I hope we will add this feature in the 2_2?
Question:
Do we want the external script to return its version number?
(Version: xyz\n")? If we ever expect a new field from the
child -- it will log "bad communication".
Should the PWQUAL_PROTOCOL_VERSION be general? We could move it
later if we want?
That's about it for now, I guess!
Regards,
Pierre B.
/*
* TODO:
*
* Doxygen documentation
* change DEBUG() code to appropriate log level
*
*/
/*
Unix SMB/CIFS implementation.
Samba utility functions
Password Quality: Help users not to choose a weak password.
Copyright (C) Andrew Bartlett 2003
Copyright (C) Pierre Belanger 2003 ([EMAIL PROTECTED])
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#include "includes.h"
/* Increment when making changes in the communication protocol */
#define PWQUAL_PROTOCOL_VERSION "1"
static void gotalarm_sig(void);
static uint32 ascii2hex(char ascii);
static int ZEROxStr2uint32(char *strx, uint32 *hex32);
static NTSTATUS password_quality_script(SAM_ACCOUNT *hnd, char *new_passwd);
static BOOL strhasctrl(const char *str);
static NTSTATUS pre_chk(const char *username,const char *fullname,char *new_pw);
static int gotalarm;
/***
Signal function to tell us we timed out.
/
static void gotalarm_sig(void)
{
gotalarm = 1;
}
/**
Main function to catch weak new passwords
**/
NTSTATUS password_quality(SAM_ACCOUNT *hnd, char *new_password)
{
NTSTATUS ntstatusresult;
ntstatusresult = password_quality_script(hnd, new_password);
if (!NT_STATUS_IS_OK(ntstatusresult)) {
DEBUG(0,("user %s could not change password NTSTATUS=0x%0.8x\n",
pdb_get_username(hnd), ntstatusresult.v));
return ntstatusresult;
}
/* Add other supports here if needed */
DEBUG(0,("user %s changed password\n", pdb_get_username(hnd)));
return(ntstatusresult);
}
/**
Run the password quality script
**/
static NTSTATUS password_quality_script(SAM_ACCOUNT *hnd, char *new_passwd)
{
int fd1[2], fd2[2];
char *cmdname;
const char *username, *fullname;
pid_t child_pid;
NTSTATUS ntprerun;
/* check if command is configured */
cmdname = lp_password_quality_script();
if (!cmdname || (*cmdname == '\0'))
return NT_STATUS_OK;
username = pdb_get_username(hnd);
fullname = pdb_get_fullname(hnd);
/* pre-run security check */
ntprerun = pre_chk(username, fullname, new_passwd);
if (! NT_STATUS_EQUAL(ntprerun, NT_STATUS_OK)) {
return ntprerun;
}
if (pipe(fd1) || pipe(fd2)) {
DEBUG(0,("could not create pipes\n"));
return NT_STATUS_ACCESS_DENIED;
}
CatchChildLeaveStatus();
child_pid = sys_fork();
if (child_pid < 0) {
CatchChild();
close(fd1[0]); close(fd1[1]);
close(fd2[0]); close(fd2[1]);
DEBUG(0,("could not fork\n"));
return NT_STATUS_A
Re: password quality script - pre-release
Shot me -- I added one line just before sending my previous mail. If you intend to compile it on your own, change "prresult" to "presult" line #261. I'm actually thinking to leave that line there, with a higher log level. Voila. Pierre B.
RE: Annoying Minor Bug In Winbind 2.2.x
On 18 Feb 2003, Martin Pool wrote :
> Jeremy already committed my patch to SAMBA_2_2 CVS.
> Here's the patch.
>
> Index: util_sock.c
> ===
> RCS file: /data/cvs/samba/source/lib/util_sock.c,v
> retrieving revision 1.16.4.36
> retrieving revision 1.16.4.37
> diff -u -u -p -r1.16.4.36 -r1.16.4.37
[snip]
I'm sorry - I'm probably doing something dumb, but I still get failures even
with this patch - first, if I save the patch as it appeared in my Outlook
window, then line 25 consists of a single left brace char, which results in
:
MYBOX:/usr/local/src/samba-2.2.7a/source/lib# patch util_sock.c
patch-util_sock-20030218
patching file util_sock.c
patch: malformed patch at line 25: {
So assuming line-wrap did something Bad to that line, I edited the patch
file to stick that line onto the end of line 24, resulting in :
MYBOX:/usr/local/src/samba-2.2.7a/source/lib# patch util_sock.c
patch-util_sock-20030218
patching file util_sock.c
Hunk #1 FAILED at 1021.
1 out of 1 hunk FAILED -- saving rejects to file util_sock.c.rej
and I don't know enough about what I'm looking at to figure it out.
> In general the best thing to do now is leave the main diff alone, and
> only work on the rejected parts in the .rej file. Basically you need
> to work out why patch thinks the 2.2 source file doesn't look like the
> "before" version of the rejected patch.
OK - hang on ... right, it seems the real original 2.2.7a util_sock.c really
*does* have the "{" on line 25 all by itself - but since that gave me
"malformed patch", I assume the patch needs a "rediff" ??? Here goes :
MYBOX:/usr/local/src/samba-2.2.7a/source/lib# rediff
patch-util_sock-20030218.orig patch-util_sock-20030218
Index: util_sock.c
===
RCS file: /data/cvs/samba/source/lib/util_sock.c,v
retrieving revision 1.16.4.36
retrieving revision 1.16.4.37
diff -u -u -p -r1.16.4.36 -r1.16.4.37
rediff: Not supported: -{
OK - I give up for now ... hlp :(
[sorry .. for all this trouble over such a minor thing]
Nick Boyce
EDS Southwest Solution Centre, Bristol, UK
-Original Message-
From: 'Martin Pool' [mailto:[EMAIL PROTECTED]]
Sent: 17 February 2003 23:08
To: Boyce, Nick
Cc: [EMAIL PROTECTED]
Subject: Re: Annoying Minor Bug In Winbind 2.2.x
Oh, Jeremy already committed my patch to SAMBA_2_2 CVS. Here's the
patch.
Index: util_sock.c
===
RCS file: /data/cvs/samba/source/lib/util_sock.c,v
retrieving revision 1.16.4.36
retrieving revision 1.16.4.37
diff -u -u -p -r1.16.4.36 -r1.16.4.37
--- util_sock.c 26 Aug 2002 20:07:13 - 1.16.4.36
+++ util_sock.c 7 Feb 2003 22:04:37 - 1.16.4.37
@@ -1021,102 +1021,97 @@ char *get_socket_addr(int fd)
/***
Create protected unix domain socket.
- some unixen cannot set permissions on a ux-dom-sock, so we
+ Some unixes cannot set permissions on a ux-dom-sock, so we
have to make sure that the directory contains the protection
- permissions, instead.
+ permissions instead.
**/
+
int create_pipe_sock(const char *socket_dir,
- const char *socket_name,
- mode_t dir_perms)
+const char *socket_name,
+mode_t dir_perms)
{
-struct sockaddr_un sunaddr;
-struct stat st;
-int sock;
-mode_t old_umask;
-pstring path;
-
-/* Create the socket directory or reuse the existing one */
-
-if (lstat(socket_dir, &st) == -1) {
-
-if (errno == ENOENT) {
-
-/* Create directory */
-
-if (mkdir(socket_dir, dir_perms) == -1) {
-DEBUG(0, ("error creating socket directory
"
- "%s: %s\n", socket_dir,
- strerror(errno)));
-return -1;
-}
-
-} else {
-
-DEBUG(0, ("lstat failed on socket directory %s:
%s\n",
- socket_dir, strerror(errno)));
-return -1;
-}
-
-} else {
-
-/* Check ownership and permission on existing directory */
-
-if (!S_ISDIR(st.st_mode)) {
-
RE: Annoying Minor Bug In Winbind 2.2.x
It's probably a line count thing. The head of the patch contains a certain
range of lines that the patch should apply to. If you truncated the patch at
the bottom, the header could be telling patch it needs to add, for example,
30 lines, while the patch text only contains 28.
Go back to the email and copy/paste lines from the email into your patch
file at the bottom, down to but not including the two dashes above Martin's
signature, and see if that helps. That line of stars is part of the patch,
and maybe a few blank lines below it. Make the part of the patch at the
bottom, below the lines with the plus signs, match what is already in the
target file.
> -Original Message-
> From: Boyce, Nick [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 18, 2003 2:58 PM
> To: [EMAIL PROTECTED]
> Cc: 'Martin Pool'
> Subject: RE: Annoying Minor Bug In Winbind 2.2.x
>
>
> On 18 Feb 2003, Martin Pool wrote :
>
> > Jeremy already committed my patch to SAMBA_2_2 CVS.
> > Here's the patch.
> >
> > Index: util_sock.c
> > ===
> > RCS file: /data/cvs/samba/source/lib/util_sock.c,v
> > retrieving revision 1.16.4.36
> > retrieving revision 1.16.4.37
> > diff -u -u -p -r1.16.4.36 -r1.16.4.37
> [snip]
>
> I'm sorry - I'm probably doing something dumb, but I still
> get failures even
> with this patch - first, if I save the patch as it appeared
> in my Outlook
> window, then line 25 consists of a single left brace char,
> which results in
> :
>
>MYBOX:/usr/local/src/samba-2.2.7a/source/lib# patch util_sock.c
> patch-util_sock-20030218
>patching file util_sock.c
>patch: malformed patch at line 25: {
>
> So assuming line-wrap did something Bad to that line, I
> edited the patch
> file to stick that line onto the end of line 24, resulting in :
>
>MYBOX:/usr/local/src/samba-2.2.7a/source/lib# patch util_sock.c
> patch-util_sock-20030218
>patching file util_sock.c
>Hunk #1 FAILED at 1021.
>1 out of 1 hunk FAILED -- saving rejects to file util_sock.c.rej
>
> and I don't know enough about what I'm looking at to figure it out.
>
> > In general the best thing to do now is leave the main diff
> alone, and
> > only work on the rejected parts in the .rej file.
> Basically you need
> > to work out why patch thinks the 2.2 source file doesn't
> look like the
> > "before" version of the rejected patch.
>
> OK - hang on ... right, it seems the real original 2.2.7a
> util_sock.c really
> *does* have the "{" on line 25 all by itself - but since that gave me
> "malformed patch", I assume the patch needs a "rediff" ???
> Here goes :
>
>MYBOX:/usr/local/src/samba-2.2.7a/source/lib# rediff
> patch-util_sock-20030218.orig patch-util_sock-20030218
>Index: util_sock.c
>===
>RCS file: /data/cvs/samba/source/lib/util_sock.c,v
>retrieving revision 1.16.4.36
>retrieving revision 1.16.4.37
>diff -u -u -p -r1.16.4.36 -r1.16.4.37
>rediff: Not supported: -{
>
> OK - I give up for now ... hlp :(
> [sorry .. for all this trouble over such a minor thing]
>
> Nick Boyce
> EDS Southwest Solution Centre, Bristol, UK
>
>
>
> -Original Message-
> From: 'Martin Pool' [mailto:[EMAIL PROTECTED]]
> Sent: 17 February 2003 23:08
> To: Boyce, Nick
> Cc: [EMAIL PROTECTED]
> Subject: Re: Annoying Minor Bug In Winbind 2.2.x
>
>
> Oh, Jeremy already committed my patch to SAMBA_2_2 CVS. Here's the
> patch.
>
>
>
>
> Index: util_sock.c
> ===
> RCS file: /data/cvs/samba/source/lib/util_sock.c,v
> retrieving revision 1.16.4.36
> retrieving revision 1.16.4.37
> diff -u -u -p -r1.16.4.36 -r1.16.4.37
> --- util_sock.c 26 Aug 2002 20:07:13 - 1.16.4.36
> +++ util_sock.c 7 Feb 2003 22:04:37 - 1.16.4.37
> @@ -1021,102 +1021,97 @@ char *get_socket_addr(int fd)
> /***
> Create protected unix domain socket.
>
> - some unixen cannot set permissions on a ux-dom-sock, so we
> + Some unixes cannot set permissions on a ux-dom-sock, so we
> have to make sure that the directory contains the protection
> - permissions, instead.
> + permissions instead.
> **/
> +
> int create_pipe_sock(const char *socket_dir,
> -
Re: interesting fact about StrCaseCmp
In the embedded/real time world, malloc() and friends are strongly deprecated as you can't predict how long they will take. They have to go through a linked list of unknown length and may even start a garbage collection. If StrCaseCmp() is really that sensitive w.r.t. processor cycles, you better keep the malloc()ed buffers between the calls and increase their size (by calling free() and malloc(), not realloc()) if the strings to be compared do not fit. (well, if the string lengths are really not limited, this may turn out as a memory leak...) Ludolf On 18 Feb 2003 at 8:04, [EMAIL PROTECTED] wrote: > On Tue, Feb 18, 2003 at 06:23:41PM +1100, Martin Pool wrote: > > > One little malloc() could hardly make it any worse, although I will do > > a test tomorrow to check. > > "One little malloc()" - I'll remind you of that quote later :-). > > But please do the test, that's the only way we can really > be sure if it's a speedup or not. > > Jeremy. > --- Ludolf Holzheid Tel:+49 621 339960 Bihl+Wiedemann GmbH Fax:+49 621 3392239 Flosswoerthstrasse 41 e-mail: [EMAIL PROTECTED] D-68199 Mannheim, Germany ---
Re: interesting fact about StrCaseCmp
On Tue, Feb 18, 2003 at 10:49:28PM +0100, Ludolf Holzheid wrote: > > In the embedded/real time world, malloc() and friends are strongly > deprecated as you can't predict how long they will take. They have to > go through a linked list of unknown length and may even start a > garbage collection. Indeed. That's why I made the "One little malloc()" joke :-). Jeremy.
"net ads join" core dump in ldap_get_values_len
Hello, I am using 3.0a21. If I use "kinit user@DOMAIN" with a user that does not have privilege to join a machine into the domain, I get core dump using "net ads join". This happens when the computer account does not exist in the domain. If the computer account exists in the domain, I get the following which is perfectly fine: [2003/02/18 13:51:59, 0] libads/ldap.c:ads_join_realm(1325) Host account for chere-2 already exists - deleting old account [2003/02/18 13:51:59, 0] libads/ldap.c:ads_join_realm(1329) Failed to delete host 'chere-2' from the 'ZHOU.COM' realm. ads_join_realm: Insufficient access The "net ads join" core dump shows: Assertion failed: (entry != NULL), function ldap_get_values_len, file getvalues.c, line 93. Abort (core dumped) A gdb back trace is: #0 0x28455cff in kill () from /usr/lib/libc.so.5 #1 0x284a7e32 in abort () from /usr/lib/libc.so.5 #2 0x2848600f in __assert () from /usr/lib/libc.so.5 #3 0x28252de1 in ldap_get_values_len () from /usr/local/lib/libldap.so.2 #4 0x814b9d3 in ads_pull_sid (ads=0x8249380, msg=0x0, field=0x819b0a1 "objectSid", sid=0xbfbff518) at libads/ldap.c:1598 #5 0x814b542 in ads_set_machine_sd (ads=0x8249380, hostname=0x81b9b90 "chere-2", dn=0x81f0440 "cn=chere-2,cn=Computers,dc=ZHOU,dc=COM") at libads/ldap.c:1431 #6 0x814a7ec in ads_add_machine_acct (ads=0x8249380, hostname=0x81b9b90 "chere-2", org_unit=0x8165ca8 "Computers") at libads/ldap.c:1085 #7 0x814b015 in ads_join_realm (ads=0x8249380, hostname=0x81b9a30 "CHERE-2", org_unit=0x8165ca8 "Computers") at libads/ldap.c:1334 #8 0x806d945 in net_ads_join (argc=0, argv=0x81b906c) at utils/net_ads.c:648 #9 0x806b196 in net_run_function (argc=1, argv=0x81b9068, table=0xbfbff7e0, usage_fn=0x806c1f0 ) at utils/net.c:97 #10 0x806e6dc in net_ads (argc=1, argv=0x81b9068) at utils/net_ads.c:1040 #11 0x806b196 in net_run_function (argc=2, argv=0x81b9064, table=0x819ee94, usage_fn=0x806f3fc ) at utils/net.c:97 #12 0x806c17b in main (argc=3, argv=0xbfbffb5c) at utils/net.c:555 #13 0x806b035 in _start () I have some problems building cvs version on my platform. So I want to know if this is fixed in cvs. "fixed" means it returns a meaningful message instead of core dump. If yes, please point me to the place I should look at. Thanks a lot ! Chere
Hi.
(i also sent this mail to samba-bugs (address posted in README) Hi. I recently downloaded samba-3.0alpha21, because I had an integration with windows 2003 Active Directory project. I am trying to use smbclient to authenticate to the Active Directory schema via Kerberos. I am able to log in and create a computer account on the PDC, but when I try to connect to a share with smbclient via the -k switch, i first recieve NT_STATUS_ACCESS_DENIED. I then rebooted the PDC and tried again. The next error I recieved was: NT_STATUS_MORE_PROCESSING_REQUIRED . That is where it is stuck. It adds the interface, spnego session gets setup, and kerberos session starts up with OS version of PDC, but then gets halted at the aorementioned error. If you can and have the time, can you please write me back and let me know if you have any possible suggestions or workarounds. Thanks :) P.S. By the way, Samba has revolutionized file and print services for linux. I and the rest of the Linux community commends you for the package :) Prashant. [EMAIL PROTECTED]
Re: Annoying Minor Bug In Winbind 2.2.x
On 18 Feb 2003, "Boyce, Nick" <[EMAIL PROTECTED]> wrote: > I'm sorry - I'm probably doing something dumb, but I still get failures even > with this patch - first, if I save the patch as it appeared in my Outlook > window, then line 25 consists of a single left brace char, which results in > : You can also download the patch from here http://pserver.samba.org/cgi-bin/cvsweb/samba/source/lib/util_sock.c.diff?r1=1.16.4.36&r2=1.16.4.37 In general you can try using "view source" to get a version that's not folded/spindled/mutilated by Outlook, or the very cool "unwrapdiff" to try to fix the line wrapping. Thanks for persisting. -- Martin
Re: interesting fact about StrCaseCmp
On 18 Feb 2003, Ludolf Holzheid <[EMAIL PROTECTED]> wrote: > In the embedded/real time world, malloc() and friends are strongly > deprecated as you can't predict how long they will take. They have > to go through a linked list of unknown length and may even start a > garbage collection. Well that's fine, but Samba is obviously not a hard real time program, so it's hardly relevant. Bear in mind that it generally runs in virtual memory and so *any* memory access can take an unboundedly long time. > If StrCaseCmp() is really that sensitive w.r.t. processor cycles, you > better keep the malloc()ed buffers between the calls and increase > their size (by calling free() and malloc(), not realloc()) if the > strings to be compared do not fit. With all due respect, this is a really silly argument. Are you not familiar with the saying that premature optimization is the root of all evil? And anyhow, if it doesn't need to be correct, it can be as fast as you like. It can just return true... If this function needs to be fast, then it should not be *copying* the strings *four* times to compare them, when comparing the first *byte* would often be enough. A minimal change to make StrCaseCmp at least not truncate strings would involve adding a malloc(), which is harmless since it's very slow already. A good implementation of StrCaseCmp shouldn't do any copying or allocation. When I get a chance I'll write that and post numbers. -- Martin
SMB_QUERY_FILE_ALL_INFO not correct in SNIA spec?
Good evening ladies and gents, The SNIA definition of the data required for SMB_QUERY_FILE_ALL_INFO does not appear to be correct. Furthermore, Ethereal's interpretation does not seem right, either. Here's what SNIA says: TIME CreationTime; TIME LastAccessTime; TIME LastWriteTime; TIME ChangeTime; ULONG Attributes; // SNIA says USHORT; Ethereal says ULONG LARGE_INTEGER AllocationSize; LARGE_INTEGER EndOfFile; ULONG NumberOfLinks; UCHAR DeletePending; UCHAR Directory; LARGE_INTEGER IndexNumber; ULONG EaSize; ULONG AccessFlags; LARGE_INTEGER IndexNumber1; // mistake in SNIA spec? LARGE_INTEGER CurrentByteOffset; ULONG Mode; ULONG AlignmentRequirement; ULONG FileNameLength; STRING FileName[]; After poking around with a sniffer, here is what I think it looks like: TIMECreationTime; TIMELastAccessTime; TIMELastWriteTime; TIMEChangeTime; ULONG Attributes; ULONG Pad1; // assumed LARGE_INTEGER AllocationSize; LARGE_INTEGER EndOfFile; ULONG NumberOfLinks; UCHAR DeletePending; UCHAR Directory; USHORT Pad2; // assumed ULONG EaSize; ULONG FileNameLength; STRING FileName[]; This is simply the concatenation of Basic Info, Standard Info (plus padding, Pad2, which is not in the SNIA spec), EA Info, and File Name Info. There is no sign of the rest of the information (internal file system index numbers, open-file information) being present. In my test I used a Win 2000 client, a Win 2000 server, and used SMB_COM_QUERY_FILE_INFORMATION (by fid, not by path). My questions: 1) Can anyone else confirm my interpretation? 2) Are there server-dependent variations on the format? thanks all for your time and best regards, Joey.
Re: SMB_QUERY_FILE_ALL_INFO not correct in SNIA spec?
On Tue, 18 Feb 2003, Joey Collins wrote: > The SNIA definition of the data required for SMB_QUERY_FILE_ALL_INFO > does not appear to be correct. Furthermore, Ethereal's interpretation > does not seem right, either. That is quite possible. We often rely on the SNIA doc, and then change things if they don't look quite right. I recall messing with one of the QUERY_FILE info levels because the attributes displayed were clearly wrong. > Here's what SNIA says: > > TIME CreationTime; > TIME LastAccessTime; > TIME LastWriteTime; > TIME ChangeTime; > ULONG Attributes; // SNIA says USHORT; Ethereal says ULONG > LARGE_INTEGER AllocationSize; > LARGE_INTEGER EndOfFile; > ULONG NumberOfLinks; > UCHAR DeletePending; > UCHAR Directory; > LARGE_INTEGER IndexNumber; > ULONG EaSize; > ULONG AccessFlags; > LARGE_INTEGER IndexNumber1; // mistake in SNIA spec? > LARGE_INTEGER CurrentByteOffset; > ULONG Mode; > ULONG AlignmentRequirement; > ULONG FileNameLength; > STRING FileName[]; > > After poking around with a sniffer, here is what I think it looks > like: > > TIMECreationTime; > TIMELastAccessTime; > TIMELastWriteTime; > TIMEChangeTime; > ULONG Attributes; > ULONG Pad1; // assumed > LARGE_INTEGER AllocationSize; > LARGE_INTEGER EndOfFile; > ULONG NumberOfLinks; > UCHAR DeletePending; > UCHAR Directory; > USHORT Pad2; // assumed > ULONG EaSize; > ULONG FileNameLength; > STRING FileName[]; One wonders why they needed a ULONG Pad in there. Perhaps it is just something we don't understand as yet. > This is simply the concatenation of Basic Info, Standard Info (plus > padding, Pad2, which is not in the SNIA spec), EA Info, and > File Name Info. There is no sign of the rest of the information > (internal file system index numbers, open-file information) being > present. > > In my test I used a Win 2000 client, a Win 2000 server, and used > SMB_COM_QUERY_FILE_INFORMATION (by fid, not by path). > > My questions: > > 1) Can anyone else confirm my interpretation? If you can send us a capture, we can look at it to see if we agree with your interpretation, and perhaps modify Ethereal as well. > 2) Are there server-dependent variations on the format? There should not be any server-dependent variations that cannot be determined by looking at WordCount or Protocol Dialect. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: SMB_QUERY_FILE_ALL_INFO not correct in SNIA spec?
Richard Sharpe wrote: > > On Tue, 18 Feb 2003, Joey Collins wrote: : > > My questions: > > > > 1) Can anyone else confirm my interpretation? > > If you can send us a capture, we can look at it to see if we agree with > your interpretation, and perhaps modify Ethereal as well. Before modifying Ethereal there will likely be more testing done... > > 2) Are there server-dependent variations on the format? > > There should not be any server-dependent variations that cannot be > determined by looking at WordCount or Protocol Dialect. ...but this is CIFS we're talking about. There are bugs introduced by different implementations. Mike Allen was able to show that W2K's WINS implementation returns invalid packets in several instances. If you are careful, you can interpret them correctly, but it really helps to know that some servers have specific quirks. 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]
RE: Samba and PPP
> Hello!
>
> Could anyone of you tell me, how to configure my Samba
> server to work with
> PPP interfaces?
> I have an Amiga machine running Samba v2.0.7. And a Windoze95 PC
> connected to it via null-modem cable.
> The problem is: Samba ignores all non-broadcast interfaces.
> So smbd and
> nmbd just do not sit on ppp0 interface, so PC can't connect
> to Samba. Also
> smbclient can't find my PC by name (i have to specify an -I
> option), because
> it ignores ppp0 too.
> After examining a source code, i found the following procedure:
> --- cut ---
> static void add_interface(struct in_addr ip, struct in_addr nmask)
> {
> struct interface *iface;
> if (iface_find(ip)) {
> DEBUG(3,("not adding duplicate interface
> %s\n",inet_ntoa(ip)));
> return;
> }
>
> if (ip_equal(nmask, allones_ip)) {
> DEBUG(3,("not adding non-broadcast interface
> %s\n",inet_ntoa(ip)));
> return;
> }
>
> iface = (struct interface *)malloc(sizeof(*iface));
> if (!iface) return;
>
> ZERO_STRUCTPN(iface);
>
> iface->ip = ip;
> iface->nmask = nmask;
> iface->bcast.s_addr = MKBCADDR(iface->ip.s_addr,
> iface->nmask.s_addr);
>
> DLIST_ADD(local_interfaces, iface);
>
> DEBUG(2,("added interface ip=%s ",inet_ntoa(iface->ip)));
> DEBUG(2,("bcast=%s ",inet_ntoa(iface->bcast)));
> DEBUG(2,("nmask=%s\n",inet_ntoa(iface->nmask)));
> }
> --- cut ---
> My interfaces are:
> --- cut ---
> 16.System:> ifconfig
> lo0: flags=C9 MTU=1536
> inet 127.0.0.1 netmask FF00
> Hardware type: Loopback
>
> eth0:
> flags=4863 MTU=1500
> inet 10.4.20.98 netmask FFFC broadcast 10.4.20.99
> Hardware type: Ethernet, address: 0:80:ad:c6:be:75
>
> ppp0:
> flags=40F1 MTU=1500
> inet 192.168.255.254 --> 192.168.255.253 netmask
> Hardware type: PPP
>
> Use "ifconfig -h" for usage.
> 16.System:>
> --- cut ---
> PC has IP 192.168.255.253.
> When i try to specify a 255.255.255.252 (FFFC) netmask
> for ppp0, Samba
> adds ppp0 to the list of interfaces, but the interface just
> does not pass
> broadcasts.
> What's wrong? How to solve my problem?
Pavel,
I had this running on my A1200 some years ago.
I think you could solve this problem with simple stuff as adding an
"lmhost" file spesifying all host in your "lan".
Broadcast are not in theory needed for operation.
There is also further mechanisms such an WINS that might help you with this issue.
Using IP based resolution should also work.
Are you sure your nmbd is running fine.
The old versions (on aminet) have some issues.
Try get the newest gcc based ports by Olaf (2.2.5 available also), nmbd is more stable
here.
Best of luck Pavel.
--
Ulf
Re: SMB_QUERY_FILE_ALL_INFO not correct in SNIA spec?
On Tue, 18 Feb 2003 22:30:44 -0800 (PST) Richard Sharpe <[EMAIL PROTECTED]> wrote: > On Tue, 18 Feb 2003, Joey Collins wrote: > > > The SNIA definition of the data required for SMB_QUERY_FILE_ALL_INFO > > does not appear to be correct. Furthermore, Ethereal's interpretation > > does not seem right, either. > > That is quite possible. We often rely on the SNIA doc, and then change > things if they don't look quite right. I recall messing with one of the > QUERY_FILE info levels because the attributes displayed were clearly > wrong. When I tried this it caused delayed blue screen in NT 4 w/ Unicode. I remember it well because I was running the client from Linux via exceed on the NT machine I was killing and it took me a couple times to realize what was happening. More evidence that if you see NT avoids an otherwise useful command (e.g. SMB_COM_COPY) it probably doesn't work. Mike -- A program should be written to model the concepts of the task it performs rather than the physical world or a process because this maximizes the potential for it to be applied to tasks that are conceptually similar and, more important, to tasks that have not yet been conceived.
Re: [Samba] RE: Samba processes
On Tue, 18 Feb 2003, Javid Abdul-AJAVID1 wrote: Abdul, We saw your first posting. Please be patient. Both smbd and nmbd run as root. All user interaction with the file system is done as the user who initiated the process. Please refer to the source code to see what happens. Samba has to ba able to perform a number of tasks that can be done only as root. > > > -Original Message- > From: Javid Abdul-AJAVID1 [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 18, 2003 11:18 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Samba processes > > > > Hi > Am noticing smbd processes are running as root and occassionally I see a > child process as userid Yep. > > Just curios under what circumstances the smbd runs as user id process ( unix > id ) and running as root is a security risk? Please explain where the security risks are. We would appreciate your patches. - John T. -- John H Terpstra Email: [EMAIL PROTECTED]
Samba processes
Hi Am noticing smbd processes are running as root and occassionally I see a child process as userid Just curios under what circumstances the smbd runs as user id process ( unix id ) and running as root is a security risk? Thanks in advance -Abdul
RE: Samba processes
-Original Message- From: Javid Abdul-AJAVID1 [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 18, 2003 11:18 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Samba processes Hi Am noticing smbd processes are running as root and occassionally I see a child process as userid Just curios under what circumstances the smbd runs as user id process ( unix id ) and running as root is a security risk? Thanks in advance -Abdul
RE: [Samba] RE: Samba processes
Thanks John Wondering y some smbd client connections show up as userid though parent is root not all client connections are show up as root. Is there a way to know when a client connection from windows side will shoup as root or user id. Thanks again -Original Message- From: John H Terpstra [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 18, 2003 1:49 PM To: Javid Abdul-AJAVID1 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Samba] RE: Samba processes On Tue, 18 Feb 2003, Javid Abdul-AJAVID1 wrote: Abdul, We saw your first posting. Please be patient. Both smbd and nmbd run as root. All user interaction with the file system is done as the user who initiated the process. Please refer to the source code to see what happens. Samba has to ba able to perform a number of tasks that can be done only as root. > > > -Original Message- > From: Javid Abdul-AJAVID1 [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 18, 2003 11:18 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Samba processes > > > > Hi > Am noticing smbd processes are running as root and occassionally I see > a child process as userid Yep. > > Just curios under what circumstances the smbd runs as user id process > ( unix id ) and running as root is a security risk? Please explain where the security risks are. We would appreciate your patches. - John T. -- John H Terpstra Email: [EMAIL PROTECTED]
