Re: use sendfile problems with Windows 95
Richard Sharpe wrote: On Thu, 27 Mar 2003, Pierre Belanger wrote: Can you get us a sniff? I sent a captured file directly to Richard. On this Friday, I wanted to share the following... While doing the capture for Richard, I was "able" to try to open different files a few times... here's what Windows 95 complained about, enjoy! Word cannot open the document. Try one or more of the following: - On the file menu, click Open to open the document - Make sure the document has a .DOC extension. (\\ALKONOST\...\CONFIG-SAVE-PROCDURE.DOC) While trying to open another file... - Word failed reading from this file (CV-belanger-EN). Please restore the network connection or replace the floppy disk and retry. (I clicked "OK" and then ...) - Word has lost data due to a bad network connection or missing floppy. Documents relying on this data are going to be saved and then closed. (I clicked "OK" and then ...) - Word cannot complete the save due to a file permission error: C:\RESCUED DOCUMENT.TXT Notes: 1) 4 out of 5 times Windows 95 just hanged when trying to open the 1st file... this time it did not hang?!?!?! 2) After doing the above tests, I mapped another drive from another Samba server not compiled with "sendfile" support. I was able to open the files properly... Cheers, Pierre B.
use sendfile problems with Windows 95
Hi, I turned on "use sendfile", not too long after (on the next "logon") someone called me. His Windows 95 was having trouble opening files on the server. He can "explore" the shared volume but when trying to open a file, his computer hangs and needs to reboot. I've been using "sendfile" myself with Samba under Solaris 8 with NT & 2000 & XP since a long time with no trouble at all. I tested with another Windows 95 box -- same problem. Even after ~ 5 min. the box is still hanged. I'm wondering if Windows 98/ME are also affected by this? I don't have access to Windows ME "boxes" but I might find a Windows 98 box... I'll post when I am able to test. I generated a level 10 log file, it's 155KB (gzip -9). Someone wants to look at it? (I did not want to post this hughe file here). Here's the first place where the communication breaks: [2003/03/27 14:53:01, 6] lib/util_sock.c:write_socket(521) write_socket(5,1588) wrote 1588 [2003/03/27 14:53:47, 0] lib/util_sock.c:read_data(436) read_data: read failure for 4. Error = Connection reset by peer [2003/03/27 14:53:47, 10] lib/util_sock.c:receive_smb(609) receive_smb: length < 0 ! [2003/03/27 14:53:47, 3] smbd/process.c:timeout_processing(1105) receive_smb error (Connection reset by peer) exiting I'll check on Microsoft's web site for any "patches"! Regards, Pierre B.
Re: Weird problems with Samba 2.2.8 under Solaris 8 + latest kernelpatch
Hi, Quick follow up... the problem was on another server. After the last reboot, not too long ago, "fast-ethernet" negotiation between the Cisco switch and the Sun server did not work properly. Cisco switch negotiated at 100Mbps/full and the Sun server in half duplex. Pierre B. Pierre Belanger wrote: Hello all, This weekend, we upgraded our Samba servers to 2.2.8 (pre3 according to the include/version.h -- CVS "synced" this past Saturday afternoon, EDT). I compiled this new release for the following Solaris/kernel : Solaris 6 : kernel patch 105181-33 Solaris 7 : kernel patch 106541-23 Solaris 8 : kernel patch 108528-19 Prior to Solaris 8 108528-19, that was installed yesterday *not by me* , we were running 108528-12. Solaris 8 with kernel patch 108518-19 + latest Samba is causing us troubles. ps : nothing changed in our smb.conf file / we had no problems before (the fcntl() bug was not an issue for us, we only have around ~ 150 concurrent connections on that machine). There's no problems on the other boxes (Solaris 6 & 7), note that we have much less connections on those boxes. [Q] Is there anyone on this list running with the latest Solaris 8 (108528-19) kernel patch and with Samba 2.2.8? After receiving a few complains, I decided to dig into the log files. Here's what I found: 1- Many dptr_close() errors, more than usually. log.wcanomp1775:[2003/03/17 14:04:09, 0] smbd/dir.c:dptr_close(277) log.wcanomp1775: Invalid key 256 given to dptr_close 2- Many oplock_break errors, much more than we had: [2003/03/17 15:32:49, 0] smbd/oplock.c:oplock_break(791) oplock_break: end of file from client oplock_break failed for file New Lisp/mbold.lsp (dev = 3d8000a, inode = 1467387, file_id = 15). [2003/03/17 15:32:49, 0] smbd/oplock.c:oplock_break(879) oplock_break: client failure in break - shutting down this smbd. [2003/03/17 15:32:49, 1] smbd/service.c:close_cnum(677) wcanomp2081 (10.10.92.33) closed connection to service imews [2003/03/17 15:32:49, 1] smbd/service.c:close_cnum(677) wcanomp2081 (10.10.92.33) closed connection to service site_doc [2003/03/17 15:32:49, 1] smbd/service.c:close_cnum(677) wcanomp2081 (10.10.92.33) closed connection to service docoss [2003/03/17 15:34:24, 1] smbd/service.c:make_connection(636) wcanomp2081 (10.10.92.33) connect to service site_doc as user imews (uid=2138, gid=240) (pid 4863) [2003/03/17 15:35:10, 0] smbd/oplock.c:request_oplock_break(1011) request_oplock_break: no response received to oplock break request to pid 4858 on port 56392 for dev = 3d8000a, inode = 825700, file_id = 15 [2003/03/17 15:35:10, 0] smbd/open.c:open_mode_check(652) open_mode_check: exlusive oplock left by process 4858 after break ! For file C 1505A/AA1710-W.dwg, dev = 3d8000a, inode = 825700. Deleting it to continue... [2003/03/17 15:35:10, 0] smbd/open.c:open_mode_check(656) open_mode_check: Existent process 4858 left active oplock. [2003/03/17 15:36:59, 1] smbd/service.c:make_connection(636) wcanomp2081 (10.10.92.33) connect to service site_doc as user imews (uid=2138, gid=240) (pid 4883) [2003/03/17 15:36:59, 0] smbd/dir.c:dptr_close(277) Invalid key 256 given to dptr_close [2003/03/17 15:36:59, 0] smbd/dir.c:dptr_close(277) Invalid key 257 given to dptr_close [2003/03/17 15:37:10, 0] smbd/oplock.c:process_local_message(397) process_local_message: Received unsolicited break reply - dumping info. [2003/03/17 15:37:10, 0] smbd/oplock.c:process_local_message(412) process_local_message: unsolicited oplock break reply from pid 4863, port 56392, dev = 3d8000a, inode = 825700, file_id = 15 [2003/03/17 15:38:02, 1] smbd/service.c:close_cnum(677) wcanomp2081 (10.10.92.33) closed connection to service site_doc [2003/03/17 15:38:09, 1] smbd/service.c:make_connection(636) wcanomp2081 (10.10.92.33) connect to service site_doc as user imews (uid=2138, gid=240) (pid 4904) [2003/03/17 15:41:22, 1] smbd/service.c:close_cnum(677) wcanomp2081 (10.10.92.33) closed connection to service imews [2003/03/17 15:41:22, 1] smbd/service.c:close_cnum(677) wcanomp2081 (10.10.92.33) closed connection to service docoss I will "downgrade" tonight to the previous version that we were running prior to the upgrade, it says "2.2.8pre1" but I remember taken that from CVS around February the 5th, according to the installation date!!! I wish I would have more time for this but I don't :-( I'll "find" time tomorrow to let you know if the downgrade helped or not. Cheers, Pierre B.
Weird problems with Samba 2.2.8 under Solaris 8 + latest kernel patch
Hello all, This weekend, we upgraded our Samba servers to 2.2.8 (pre3 according to the include/version.h -- CVS "synced" this past Saturday afternoon, EDT). I compiled this new release for the following Solaris/kernel : Solaris 6 : kernel patch 105181-33 Solaris 7 : kernel patch 106541-23 Solaris 8 : kernel patch 108528-19 Prior to Solaris 8 108528-19, that was installed yesterday *not by me* , we were running 108528-12. Solaris 8 with kernel patch 108518-19 + latest Samba is causing us troubles. ps : nothing changed in our smb.conf file / we had no problems before (the fcntl() bug was not an issue for us, we only have around ~ 150 concurrent connections on that machine). There's no problems on the other boxes (Solaris 6 & 7), note that we have much less connections on those boxes. [Q] Is there anyone on this list running with the latest Solaris 8 (108528-19) kernel patch and with Samba 2.2.8? After receiving a few complains, I decided to dig into the log files. Here's what I found: 1- Many dptr_close() errors, more than usually. log.wcanomp1775:[2003/03/17 14:04:09, 0] smbd/dir.c:dptr_close(277) log.wcanomp1775: Invalid key 256 given to dptr_close 2- Many oplock_break errors, much more than we had: [2003/03/17 15:32:49, 0] smbd/oplock.c:oplock_break(791) oplock_break: end of file from client oplock_break failed for file New Lisp/mbold.lsp (dev = 3d8000a, inode = 1467387, file_id = 15). [2003/03/17 15:32:49, 0] smbd/oplock.c:oplock_break(879) oplock_break: client failure in break - shutting down this smbd. [2003/03/17 15:32:49, 1] smbd/service.c:close_cnum(677) wcanomp2081 (10.10.92.33) closed connection to service imews [2003/03/17 15:32:49, 1] smbd/service.c:close_cnum(677) wcanomp2081 (10.10.92.33) closed connection to service site_doc [2003/03/17 15:32:49, 1] smbd/service.c:close_cnum(677) wcanomp2081 (10.10.92.33) closed connection to service docoss [2003/03/17 15:34:24, 1] smbd/service.c:make_connection(636) wcanomp2081 (10.10.92.33) connect to service site_doc as user imews (uid=2138, gid=240) (pid 4863) [2003/03/17 15:35:10, 0] smbd/oplock.c:request_oplock_break(1011) request_oplock_break: no response received to oplock break request to pid 4858 on port 56392 for dev = 3d8000a, inode = 825700, file_id = 15 [2003/03/17 15:35:10, 0] smbd/open.c:open_mode_check(652) open_mode_check: exlusive oplock left by process 4858 after break ! For file C 1505A/AA1710-W.dwg, dev = 3d8000a, inode = 825700. Deleting it to continue... [2003/03/17 15:35:10, 0] smbd/open.c:open_mode_check(656) open_mode_check: Existent process 4858 left active oplock. [2003/03/17 15:36:59, 1] smbd/service.c:make_connection(636) wcanomp2081 (10.10.92.33) connect to service site_doc as user imews (uid=2138, gid=240) (pid 4883) [2003/03/17 15:36:59, 0] smbd/dir.c:dptr_close(277) Invalid key 256 given to dptr_close [2003/03/17 15:36:59, 0] smbd/dir.c:dptr_close(277) Invalid key 257 given to dptr_close [2003/03/17 15:37:10, 0] smbd/oplock.c:process_local_message(397) process_local_message: Received unsolicited break reply - dumping info. [2003/03/17 15:37:10, 0] smbd/oplock.c:process_local_message(412) process_local_message: unsolicited oplock break reply from pid 4863, port 56392, dev = 3d8000a, inode = 825700, file_id = 15 [2003/03/17 15:38:02, 1] smbd/service.c:close_cnum(677) wcanomp2081 (10.10.92.33) closed connection to service site_doc [2003/03/17 15:38:09, 1] smbd/service.c:make_connection(636) wcanomp2081 (10.10.92.33) connect to service site_doc as user imews (uid=2138, gid=240) (pid 4904) [2003/03/17 15:41:22, 1] smbd/service.c:close_cnum(677) wcanomp2081 (10.10.92.33) closed connection to service imews [2003/03/17 15:41:22, 1] smbd/service.c:close_cnum(677) wcanomp2081 (10.10.92.33) closed connection to service docoss I will "downgrade" tonight to the previous version that we were running prior to the upgrade, it says "2.2.8pre1" but I remember taken that from CVS around February the 5th, according to the installation date!!! I wish I would have more time for this but I don't :-( I'll "find" time tomorrow to let you know if the downgrade helped or not. Cheers, Pierre B.
Re: Solaris fcntl CPU/Lock update
I first thought that the libraries were not threaded but it
appears they are. But you have a compile options to disable
threads.
alkonost{pbelang1}-openldap-2.1.4% ./configure --help|grep -i thread
--with-threads with threads [auto]
Don't know what the impacts are but since Samba is non-threaded
I guess there's no impact in compile the libraries with the
"--without-threads" option.
Pierre B.
Pierre Belanger wrote:
Did you try to compile using OpenLDAP? I think that can
be a "quick" fix.
Otherwise, open a ticket with Sun?
Pierre B.
Jeff Mandel wrote:
trace from 12327:
(gdb) bt
#0 0xfecd9794 in __sigprocmask () from /usr/lib/libthread.so.1
#1 0xfecce1e8 in _deliversigs () from /usr/lib/libthread.so.1
#2 0xfecd05c4 in thr_sigsetmask () from /usr/lib/libthread.so.1
#3
#4 0xb in ?? ()
#5 0xfecdb1f0 in usleep () from /usr/lib/libthread.so.1
#6 0xf7d1c in do_lock_spin (fsp=0x26da48, conn=0x257c68, lock_pid=0,
count=20, offset=2147483559, lock_type=WRITE_LOCK) at
locking/locking.c:175
#7 0x58bb4 in reply_lockingX (conn=0x257c68, inbuf=0x2173c9 "",
outbuf=0x237819 "", length=75, bufsize=16644) at smbd/reply.c:4714
#8 0x739bc in switch_message (type=36, inbuf=0x2173c9 "",
outbuf=0x237819 "",
size=75, bufsize=16644) at smbd/process.c:774
#9 0x73a48 in construct_reply (inbuf=0x2173c9 "", outbuf=0x237819 "",
size=75, bufsize=16644) at smbd/process.c:803
#10 0x73cf4 in process_smb (inbuf=0x2173c9 "", outbuf=0x237819 "")
at smbd/process.c:897
#11 0x74814 in smbd_process () at smbd/process.c:1294
#12 0x314b4 in main (argc=0, argv=0xffbefeac) at smbd/server.c:832
(gdb) The program is running. Quit anyway (and detach it)? (y or n) y
This is a much more interesting backtrace than the
other. Why is smbd linking in pthread libraries ?
smbd is *NOT* a threaded program.
The backtrace you have here shows smbd trying to get
a fcntl lock on behalf of a client and failing to get it
instantaneously, so going into the lock spin code. It
will try 3 times, sleeping for 10 usec between each attempt,
and then return a fail to the client. This is not in itself
a spinning bug or problem, smbd is meant to do this.
I'm worried about the interaction between the Solaris lwp
libc code and smbd smbd should be a simple program
with only one thread of execution.
Jeremy.
Since it seems that libthread shows up because nss_ldap (padl's) is
used, does anyone have suggestions for dealing with this at the
nss_ldap level?
Jeff
Re: Solaris fcntl CPU/Lock update
Did you try to compile using OpenLDAP? I think that can be a "quick" fix. Otherwise, open a ticket with Sun? Pierre B. Jeff Mandel wrote: trace from 12327: (gdb) bt #0 0xfecd9794 in __sigprocmask () from /usr/lib/libthread.so.1 #1 0xfecce1e8 in _deliversigs () from /usr/lib/libthread.so.1 #2 0xfecd05c4 in thr_sigsetmask () from /usr/lib/libthread.so.1 #3 #4 0xb in ?? () #5 0xfecdb1f0 in usleep () from /usr/lib/libthread.so.1 #6 0xf7d1c in do_lock_spin (fsp=0x26da48, conn=0x257c68, lock_pid=0, count=20, offset=2147483559, lock_type=WRITE_LOCK) at locking/locking.c:175 #7 0x58bb4 in reply_lockingX (conn=0x257c68, inbuf=0x2173c9 "", outbuf=0x237819 "", length=75, bufsize=16644) at smbd/reply.c:4714 #8 0x739bc in switch_message (type=36, inbuf=0x2173c9 "", outbuf=0x237819 "", size=75, bufsize=16644) at smbd/process.c:774 #9 0x73a48 in construct_reply (inbuf=0x2173c9 "", outbuf=0x237819 "", size=75, bufsize=16644) at smbd/process.c:803 #10 0x73cf4 in process_smb (inbuf=0x2173c9 "", outbuf=0x237819 "") at smbd/process.c:897 #11 0x74814 in smbd_process () at smbd/process.c:1294 #12 0x314b4 in main (argc=0, argv=0xffbefeac) at smbd/server.c:832 (gdb) The program is running. Quit anyway (and detach it)? (y or n) y This is a much more interesting backtrace than the other. Why is smbd linking in pthread libraries ? smbd is *NOT* a threaded program. The backtrace you have here shows smbd trying to get a fcntl lock on behalf of a client and failing to get it instantaneously, so going into the lock spin code. It will try 3 times, sleeping for 10 usec between each attempt, and then return a fail to the client. This is not in itself a spinning bug or problem, smbd is meant to do this. I'm worried about the interaction between the Solaris lwp libc code and smbd smbd should be a simple program with only one thread of execution. Jeremy. Since it seems that libthread shows up because nss_ldap (padl's) is used, does anyone have suggestions for dealing with this at the nss_ldap level? Jeff
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.
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();
cl
Re: password quality script aka --with-cracklib replacement
Hi,
I started this mail yesterday ... 24h/day is not enough since
the past few days :(
First of all, I forget to state in the documentation that the external
program also needs to send a ".\n" on a new line after sending the
"required" fields.
1) "Don't use recent password" feature:
I did not want to focuss on this feature yet but since it came
up on the list, lets do it ;-) This was actually the next thing
I thought of doing in terms on contribution to Samba!!!
a) If we want the password-quality script to handle this,
I think we'll all agree, storing clear text password is really
not a good idea. Perhaps the interface should provide the new
encrypted passwords to the external program -- if administrators
don't have "easy access" to the encrypted password, some will
probably endup use the cleartext one :(
b) My idea was to incorporate this directly within smbd creating a
database, tdb? but I have no clue on the specifications of tdb
database -- perhaps I'm writing something really stupid here :)
If it's not possible with tdb, I guess we could use something
else. I would be much better, in term of security, to store the
old passwords using MD5 or even Blowfish (is it legal to
distribute such encryption mechanism in Samba -- I'm thinking
of the US encryption law restricting exportation).
Any experts around?
I also think that such of "module" requires to remove all data
from the "old password database" when a user is deleted. Or we
provide a tool for systems administrators that checks if there
is still a match between what's in the "old pw db" and the
"pdb" / smbpasswd file, etc!?! If you have a clue now on how
to achieve this, great -- otherwise we'll think of this when
we get there!
2) PAM module
I'll leave this to someone else. I really think PAM rocks but
if we want to support this new feature on every supported OS
by Samba, I think we should not go PAM. Is PAM standard on
all Unix flavors? Will Windows ever support PAM? (Ain't someone
in this world trying to port Samba to Windows? -- I wouldn't be
surprised, LOL).
Ain't people moving towards pdb LDAP backend using the included
LDAP support in Samba instead of using PAM?
3) "Failed" script
Yes, if the script fails to run or return an exit status != 0,
smbd deny the change request.
4) Root / non-root
We could add an attribute "password quality runas root (true/false)"
in smb.conf . Should we?
5) "Protocol"
Do we agree on the following for "version: 1\n"?
- Version starts @ 1
- Space added ... "Field: value\n" -- External can return
with or without a space. I think on the answer we can be
a little bit "flexible", is that fine?
- Send empty string value if a "value" is not available:
"Fullname: \n"
- I agree with Andrew -- "string protocol is much easier to
implement / debug". I don't know how the fullname will be
passed to the external if there are "funky" characters, I know
this is not a problem with the other Fields. Perhaps for
release #1 we don't send the "fullname"?
If we need some type of "encoding / decoding" mechanism,
shouldn't we use something already "very popular". If it's
too complicated, people won't use it.
- Returned NTSTATUS. Allow both string and hex or not?
The code presently does this: ... pnstatus is the "NTStatus"
returned value. presult is the "Result" (debug info) returned
value.
/* Match returned NT status from external program */
ntstatusmap = nt_status_string_to_code(pntstatus);
if NT_STATUS_EQUAL(ntstatusmap, NT_STATUS_UNSUCCESSFUL) {
DEBUG(1,("Undefined NTSTATUS %s received from %s\n",
pntstatus, cmdname));
DEBUG(1,("user %s could not change password - %s\n",
username, presult));
return NT_STATUS_ACCESS_DENIED;
}
if (!NT_STATUS_IS_OK(ntstatusmap)) {
DEBUG(1,("user %s could not change password - %s\n",
username, presult));
return ntstatusmap;
}
return NT_STATUS_ACCESS_DENIED;
If tomorrow there is a new "return code" available, it will work
once it is added in "nterr.h".
When I first wrote the documentation I wrote something like:
"we suggest that you use one of the following NTSTATUS for this
context" but I figured perhaps the protocol should not be
flexible. Either when there's a new NTSTATUS for this context,
we had it in "nterr.h" and password-quality.c OR we leave it
like it is now, i.e. accept anything defined in "nterr.h".
Honestly, I'm still not sure if we should allow both. I know I don't
really like the idea of smbd returning something not defined in
"nterr.h".
True "protocols" always use numeric values. "440 - File not found" !
If we have to modify the source code when we need to add a new
supported returned value, I think we'd rather just need to add this
new "value" in nterr.h and Voila!
- Password field -- "injection attacks
Password changing - root bug?
Hello all,
While digging (yes I'm still ;-) into the password changing code
I found something that I find strange.
We know that running smbpasswd on the locally as non-root
or root, it's two different paths in the code. Here's where
I want to get.
As non-root, smbpasswd connects to the smbd. Soon or later,
smbd ends up in chgpasswd() file "smbd/chgpasswd.c".
chgpasswd() calls:
- change_oem_password()
- pdb_update_sam_account()
In "change_oem_password()" beginning @ line # 510 it says:
* Check the old and new passwords don't contain any control
* characters.
If there is a ctrl character in the password, it won't change
it, and it returns an error to chgpasswd(). The code will never
reach pdb_update_sam_account() .
Running smbpasswd locally as root, it's possible to put ctrl
characters in the "new password". I did not find a place, yet!,
check for ctrl characters. From my tests, it's not possible to
log on a Windows machine using ctrl characters in a password.
Shouldn't we verify somewhere in the "pdb_*" code if there's
a ctrl char in the new password? Or perhaps in
"pdb_set_plaintext_passwd" or perhaps far in the code, in
"pdb_set_{nt_passwd|lanman_passwd|...}" ??
I could have dig a little bit more, I'll leave this in expert
hands!
Thank you,
Pierre B.
password quality script aka --with-cracklib replacement
Hi,
Here's what I've come up for the "password quality script",
cracklib "replacement" after exchanging a few email and reading
what came up on the mailing list. Your comments are again very
welcome -- I've come up with this but if it's all wrong fell
free to "blast me" ;-) I had good fun doing it and if something
needs to be change, I'll be happy to change it! The code, the
documentation and an example script are ready. I even stepped
out of the code a few days came back and made a few more
changes.
1) cracklib
The idea to have cracklib (v2.7) directly linked in smbd was
abandon because it was adding support *only* for cracklib
and a few changes were required in cracklib's code. Cracklib
is under "artistic" license which is not compatible with GNU,
etc.
2) password quality script
What is it? I have my own comments at the end ...
From the documentation I wrote (even if I'm French I think it's not
that bad!?!?!?):
Full path to the script that will be called when a
request for change password is received. It will be run
by smbd as non-ROOT.
The script is responsible to accept or refuse the new
password based on its own rules. As an example, it can
be a script refusing a weak password based on a dic-
tionary word.
Samba back end communicates with the password quality
program by writing data to its STDIN and reading data
from its STDOUT. Samba writes a block of data in
"Field:value\n" terminated by a ".\n" at the beginning
of a new line.
1) smbd to ---> Password quality script "STDIN"
Version:smbd-version-string\n
Username:username\n
Fullname:fullname\n
Password:new-password\n
.\n
The above fields are filled with their respective
value. Once smbd writes on the last line ".\n", it
waits from the script its response and exit status.
IMPORTANT NOTES: The "smbd-version-string" may contain
alpha characters, for example: 2.2.8pre1. The "new-
password" may have a leading or trailing space -- be
carefull when parsing the data.
2) Password quality script "STDOUT" to ---> smbd
NTStatus:ntstatus-string\n
Result:result-string\n
.\n
The "ntstatus-string" value must used one the pre-
defined NTSTATUS (nterr.h) values. In this context:
NT_STATUS_OK # New password accepted
NT_STATUS_ACCESS_DENIED # Error occured in the script
NT_STATUS_PASSWORD_RESTRICTION # Too short, weak, etc.
The "result-string" value is used to provide informa-
tion (debug info) to smbd. For examples:
NTStatus:NT_STATUS_PASSWORD_RESTRICTION\n
Result:Password is based on dictionary word\n
or
NTStatus:NT_STATUS_OK\n
Result:New password is accepted\n
smbd will always return an error to the client and does
not change the current password unless the NTStatus
value is equal to "NT_STATUS_OK" and the exit status of
the script equal to 0.
Default: password quality script =
Example: password quality script =
/usr/local/samba/sbin/password-quality.pl
Do you wonder why sending the "smbd-version-string"? Perhaps
in the future a new NTSTATUS will be added. The only way for the
external program to know if it can use the new value is by
knowing the version of Samba! There are other possible examples.
[Q] What do we do with the fullname? We don't care? What if it's not
available ('\0')? Do we write to the external program an empty string
like this ->Fullname:\n<- or we just don't send the fullname field
to the external program or perhaps something like "Fullname:Unknown\n"?
I think -- either we always send something (Unknown when it's empty)
or we just don't send it. I think it's less confusing for everyone
is we write in the documentation if fullname is not known, we write
"Unknown" (or empty or NULL!).
Let me know what you think and/or other ideas.
Thank you again,
Pierre B.
Re: Solaris fcntl CPU/Lock update
Jeff, Ok, you're using nss_ldap from PDAL to use /etc/nsswitch.conf like passwd: ldap files (or reverse) group: ldap files etc Right? (From what I recall that's what nss_ldap is used for). If you did not compile with Samba, it means that if you do "ldd" on "smbd" it should not print "libthread" or "libpthread". Is this the result you get? If this is the result you get -- than I REALLY don't understand how "smbd" process opens libthread and libpthread! I get this @ home from 2.2."pre-8" (I CVS sync everyday every once and a while). libsec.so.1 => /usr/lib/libsec.so.1 libgen.so.1 => /usr/lib/libgen.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libpam.so.1 => /usr/lib/libpam.so.1 libsendfile.so.1 => /usr/lib/libsendfile.so.1 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-2/lib/libc_psr.so.1 If you don't have this problem on the other box, it can be a Solaris bug introduced lately. The binaries you run on both boxes don't "differ", right? They are the same "exact" copy? Pierre B.
Re: Solaris fcntl CPU/Lock update
Hello all,
Andrew, true GDB is thread aware but I think last time I used
it (back in ~ 1998) I was writing a multi-threaded application
and I really remember like if it was yesterday: GDB was not
thread aware at that time. I'm glad to hear it's now thread
aware!
I found the following if it can help us debug this thing
with Jeff Mandel (the original poster).
Debugging multi-threaded applications with GDB...
http://www-es.fernuni-hagen.de/cgi-bin/info2html?(gdb)Threads
Like Andrew suggested -- I ran nm on libthread.so. I almost
felt off my chair!
From libthread.so
[905] |111016| 84|FUNC |GLOB |0|9 |usleep
There exists under Solaris a usleep in libthread.so !!!
Of course, as well in libc.so.
From libc.so :
usleep [3265] |635736| 40|FUNC |WEAK |0|9 |usleep
This here :
#0
#1 0xfecd9794 in __sigprocmask () from /usr/lib/libthread.so.1
#2 0xfecce148 in _sigon () from /usr/lib/libthread.so.1
#3 0xfecd05bc in thr_sigsetmask () from /usr/lib/libthread.so.1
#3 0xfecd05bc in thr_sigsetmask () from /usr/lib/libthread.so.1
#4
#5 0x65646974 in ?? ()
#6 0xfecdb1f0 in usleep () from /usr/lib/libthread.so.1
The "called signal handler" of "usleep" *in* libpthread.so.1
uses thr_sigsetmask and the above funtions, for the only
reason that some LDAP library needs libthread.so???
I can't go any further now, ho yes I can just before I was
going to hit send ;-) Here's what I did:
After "Hello World" ...
int main (int argc, char **argv){usleep(1);}
Compiled using "gcc sleeping.c" and after I compiled using
"gcc sleeping.c -lthread". HAHA!!! Here's the results.
1) Without linking with libhread:
/1: execve("a.out", 0xFFBEFB0C, 0xFFBEFB14) argc = 1
/1: mmap(0x, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF3A
/1: resolvepath("/usr/lib/ld.so.1", "/usr/lib/ld.so.1", 1023) = 16
/1: open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
/1: stat("/usr/lib/libc.so.1", 0xFFBEF234) = 0
/1: open("/usr/lib/libc.so.1", O_RDONLY)= 3
/1: fstat(3, 0xFFBEF234)= 0
/1: mmap(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xFF39
/1: mmap(0x, 802816, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0)
= 0xFF28
/1: mmap(0xFF33C000, 24748, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 704512) = 0xFF33C000
/1: munmap(0xFF32C000, 65536) = 0
/1: memcntl(0xFF28, 113448, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
/1: close(3)= 0
/1: stat("/usr/lib/libdl.so.1", 0xFFBEF234) = 0
/1: open("/usr/lib/libdl.so.1", O_RDONLY) = 3
/1: fstat(3, 0xFFBEF234)= 0
/1: mmap(0xFF39, 8192, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFF39
/1: close(3)= 0
/1: stat("/usr/platform/SUNW,Ultra-2/lib/libc_psr.so.1", 0xFFBEF0C4) = 0
/1: open("/usr/platform/SUNW,Ultra-2/lib/libc_psr.so.1", O_RDONLY) = 3
/1: fstat(3, 0xFFBEF0C4)= 0
/1: mmap(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xFF38
/1: mmap(0x, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0)
= 0xFF37
/1: close(3)= 0
/1: munmap(0xFF38, 8192)= 0
/1: alarm(0)= 0
/1: setitimer(ITIMER_REAL, 0xFFBEFA28, 0xFFBEFA18) = 0
/1: sigaction(SIGALRM, 0xFFBEF928, 0xFFBEF9D8) = 0
/1: sigfillset(0xFF3428B8) = 0
/1: sigprocmask(SIG_BLOCK, 0xFFBEF9C8, 0xFFBEF9B8) = 0
/1: setitimer(ITIMER_REAL, 0xFFBEFA28, 0x) = 0
/1: Received signal #14, SIGALRM, in sigsuspend() [caught]
/1: sigsuspend(0xFFBEF9A8) Err#4 EINTR
/1: setcontext(0xFFBEF690)
/1: sigaction(SIGALRM, 0xFFBEF928, 0x) = 0
/1: sigprocmask(SIG_UNBLOCK, 0xFFBEF9C8, 0x) = 0
/1: setitimer(ITIMER_REAL, 0xFFBEFA18, 0x) = 0
/1: llseek(0, 0, SEEK_CUR) = 38123
/1: _exit(0)
2) Compiled with -lthread ... hard to beleive, 5 threads
to make a simple "usleep(1)" system call!!!
/1: execve("ta.out", 0xFFBEFB0C, 0xFFBEFB14) argc = 1
/1: mmap(0x, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF3A
/1: resolvepath("/usr/lib/ld.so.1", "/usr/lib/ld.so.1", 1023) = 16
/1: open("/var/ld/ld.config", O_RDONLY) Err#2 ENOENT
/1: stat("/usr/lib/libthread.so.1", 0xFFBEF234) = 0
/1: open("/usr/lib/libthread.so.1", O_RDONLY) = 3
/1: fstat(3, 0xFFBEF234)= 0
/1: mmap(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xFF39
/1: mmap(0x, 245760, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0
Re: Solaris fcntl CPU/Lock update
Hello, David Collier-Brown -- Customer Engineering wrote: "Christopher R. Hertel" wrote: indirectly to you from pbelanger: Thanx Christopher to forward the info. Please let know jra that libnspr4.so and libnss3.so ARE linked to libpthread and libthread under Solaris I assume libnspr4.so and libnss3.so are special libraries provided as part of open LDAP: the Solaris nss libraries are nss_compat.so.1 nss_files.so.1nss_nis.so.1 nss_user.so.1 nss_dns.so.1 nss_ldap.so.1 nss_nisplus.so.1 nss_xfn.so.1 with nothing resembling libnss3, while there are no nspr libraries at all. I did a quick check, and there are no solaris libraries which make calls into libposix... I would suggest to compile Samba using OpenLDAP instead of Sun's (Netscape) LDAP libraries and see if there's still a problem. The back-trace looks *very* weird. gdb is not "thread aware" as far as I remember? Could it be the reason why the back-trace is "weird"? I'd seriously think of compiling using OpenLDAP, I'd like to see the results. I'm even thinking of download Sun's SDK and play around with it to see if I get the same problem here, but I'm way too busy for the next few days. Cheers, Pierre B.
Re: A Union of two directories
Arthur, If there is a collision (2 or more directories with the same name), what do you think would be the best thing to do? I understand the idea of merging "2 directories", I think I would use such a "feature". I think the "VFS module" should actually support "n" directories. For the moment, can't you create a symbolic link? Pierre B. Arthur Barrett wrote: Hi All! I am new to Samba and this group and I have a question... My company wants to make a "custom" version of Samba which is capable of creating a "share" which is actually a union of two directories. ie: instead of the share "\\samba\arthur" being /home/arthur, we want the share "\\samba\arthur" to be the union of the two directories /home/common and /home/arthur Why? It's all to do with version control and limitations in other software. The idea is to create a "reserved checkout" in a single directory. ie: all the "read only" code is in /home/common and the "checked out" code is in /home/arthur", but the silly end product software wants all the files in 1 directory (\\samba\arthur). Oh woe is me! So my question is: which source code file is the one that actually opens files in the unix file system ? Additionally - is anyone else interested in the result ? Regards, Arthur Barrett
Re: incorrect password length - bug?
Jerry, Gerald (Jerry) Carter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 29 Jan 2003, Pierre Belanger wrote: Reference: http://lists.samba.org/pipermail/samba-technical/2001-August/015596.html I was playing around with smbpasswd last night. I first thought something committed in CVS broke something, I checked all changes made since the past 1-2 days and found nothing :( I than downgraded to an old copie of samba I kept and was quite surprised to see I was still having the same behavior! Here we go. Using smbpasswd -r localhost -U if you type in the wrong current (old) password, smbd reports: [2003/01/29 14:13:05, 0] smbd/chgpasswd.c:check_oem_password(817) check_oem_password: incorrect password length (1980737076). This value comes from new_pw_len = IVAL(lmdata, 512) in chgpasswd.c . I tried hard to find the reason, even with debug level @ 9, I can't :( The passeord change is done by sending a large buffer and encrypting it with the old password. The first 512 bytes a random junk and the clear text of the new password is tagged on. Since you used a wrong old password, the buffer cannot be decryptesd correctly when smbd uses the correct password. Thus the length field is invalid. Make sense? It's encrypted, no wonder why I did not understand nothing ;-) Yes, it all makes much more sense now. I could be more specific, but I would need to look back at that code again to refresh my memory. If the calculated new_pw_length is incorrect, doesn't this always mean that the supplied password is wrong? Can't we log something like: "old supplied password not good" or "bad pass length (%d) - old supplied passwd wrong". I might be missing something *else*. I haven't checked all layers in smbd, I guess we do check somewhere the length of "lmdata" in case it's too short way before we get to IVAL(lmdata, 512)... so IVAL doesn't try to "read in the memory" from somewhere it shouldn't (it's not a buffer overflow just can't remember the right English expression!). I'll learn by myself all the "Samba internal layers" one day... no need to comment on this. Thanx for your time, Pierre B.
Re: incorrect password length - bug?
I forgot to mention this is under "LANMAN" . I attached a debug 9 "output". If the supplied password is not good, we shouldn't get that far... I guess? Unless there's something I don't get... I tried to change in lanman.c api_SamOEMChangePassword to "anon not Ok" by adding "True" for fun, didn't work ;-) Regards, Pierre B. Pierre Belanger wrote: Hi, Before writing this mail, I queried google (there's so many Samba installation hoping I could find an answer!). I did find an old message posted on samba-technical back in 2001 but my query did not lead me to *the* answer. Reference: http://lists.samba.org/pipermail/samba-technical/2001-August/015596.html I was playing around with smbpasswd last night. I first thought something committed in CVS broke something, I checked all changes made since the past 1-2 days and found nothing :( I than downgraded to an old copie of samba I kept and was quite surprised to see I was still having the same behavior! Here we go. Using smbpasswd -r localhost -U if you type in the wrong current (old) password, smbd reports: [2003/01/29 14:13:05, 0] smbd/chgpasswd.c:check_oem_password(817) check_oem_password: incorrect password length (1980737076). This value comes from new_pw_len = IVAL(lmdata, 512) in chgpasswd.c . I tried hard to find the reason, even with debug level @ 9, I can't :( Same behavior under both 2.2.x and 3.0. I have to admit it was a nice XP (experience) to dig around the source code. Perhaps I need better glasses, LOL! ;-) Thank you, Pierre B. [2003/01/29 13:58:40, 6] param/loadparm.c:lp_file_list_changed(2328) lp_file_list_changed() file /usr/local/samba3/lib/smb.conf -> /usr/local/samba3/lib/smb.conf last mod_time: Wed Jan 29 11:23:53 2003 [2003/01/29 13:58:40, 3] smbd/oplock.c:init_oplocks(1212) open_oplock_ipc: opening loopback UDP socket. [2003/01/29 13:58:40, 3] smbd/oplock.c:init_oplocks(1243) open_oplock ipc: pid = 2344, global_oplock_port = 46477 [2003/01/29 13:58:40, 4] lib/time.c:get_serverzone(122) Serverzone is 18000 [2003/01/29 13:58:40, 3] lib/access.c:check_access(311) check_access: no hostnames in host allow/deny list. [2003/01/29 13:58:40, 2] lib/access.c:check_access(322) Allowed connection from (127.0.0.1) [2003/01/29 13:58:40, 6] smbd/process.c:process_smb(881) got message type 0x0 of len 0xb3 [2003/01/29 13:58:40, 3] smbd/process.c:process_smb(882) Transaction 0 of length 183 [2003/01/29 13:58:40, 5] lib/util.c:show_msg(461) [2003/01/29 13:58:40, 5] lib/util.c:show_msg(471) size=179 smb_com=0x72 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=8 smb_flg2=2049 smb_tid=0 smb_pid=2343 smb_uid=0 smb_mid=1 smt_wct=0 smb_bcc=144 [2003/01/29 13:58:40, 3] smbd/process.c:switch_message(676) switch message SMBnegprot (pid 2344) [2003/01/29 13:58:40, 3] smbd/sec_ctx.c:set_sec_ctx(288) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 [2003/01/29 13:58:40, 5] auth/auth_util.c:debug_nt_user_token(481) NT user token: (NULL) [2003/01/29 13:58:40, 5] auth/auth_util.c:debug_unix_user_token(500) UNIX token of user 0 Primary group is 0 and contains 0 supplementary groups [2003/01/29 13:58:40, 5] smbd/uid.c:change_to_root_user(218) change_to_root_user: now uid=(0,0) gid=(0,0) [2003/01/29 13:58:40, 3] smbd/negprot.c:reply_negprot(427) Requested protocol [PC NETWORK PROGRAM 1.0] [2003/01/29 13:58:40, 3] smbd/negprot.c:reply_negprot(427) Requested protocol [MICROSOFT NETWORKS 1.03] [2003/01/29 13:58:40, 3] smbd/negprot.c:reply_negprot(427) Requested protocol [MICROSOFT NETWORKS 3.0] [2003/01/29 13:58:40, 3] smbd/negprot.c:reply_negprot(427) Requested protocol [LANMAN1.0] [2003/01/29 13:58:40, 3] smbd/negprot.c:reply_negprot(427) Requested protocol [LM1.2X002] [2003/01/29 13:58:40, 3] smbd/negprot.c:reply_negprot(427) Requested protocol [DOS LANMAN2.1] [2003/01/29 13:58:40, 3] smbd/negprot.c:reply_negprot(427) Requested protocol [Samba] [2003/01/29 13:58:40, 6] param/loadparm.c:lp_file_list_changed(2328) lp_file_list_changed() file /usr/local/samba3/lib/smb.conf -> /usr/local/samba3/lib/smb.conf last mod_time: Wed Jan 29 11:23:53 2003 [2003/01/29 13:58:40, 6] param/loadparm.c:lp_file_list_changed(2328) lp_file_list_changed() file /usr/local/samba3/lib/smb.conf -> /usr/local/samba3/lib/smb.conf last mod_time: Wed Jan 29 11:23:53 2003 [2003/01/29 13:58:40, 3] smbd/negprot.c:reply_nt1(301) using SPNEGO [2003/01/29 13:58:40, 3] smbd/negprot.c:reply_negprot(504) Selected protocol NT LANMAN 1.0 [2003/01/29 13:58:40, 5] smbd/negprot.c:reply_negprot(510) negprot index=7 [2003/01/29 13:58:40, 5] lib/util.c:show_msg(461) [2003/01/29 13:58:40, 5] lib/util.c:show_msg(471) size=127 smb_com=0x72 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=18433 smb_tid=0 smb_pid=2343 smb_uid=0 smb_mid=1 smt_wct=17 smb_vwv[ 0]=7 (0x7) smb_vwv[ 1]=12803 (0x3203)
incorrect password length - bug?
Hi, Before writing this mail, I queried google (there's so many Samba installation hoping I could find an answer!). I did find an old message posted on samba-technical back in 2001 but my query did not lead me to *the* answer. Reference: http://lists.samba.org/pipermail/samba-technical/2001-August/015596.html I was playing around with smbpasswd last night. I first thought something committed in CVS broke something, I checked all changes made since the past 1-2 days and found nothing :( I than downgraded to an old copie of samba I kept and was quite surprised to see I was still having the same behavior! Here we go. Using smbpasswd -r localhost -U if you type in the wrong current (old) password, smbd reports: [2003/01/29 14:13:05, 0] smbd/chgpasswd.c:check_oem_password(817) check_oem_password: incorrect password length (1980737076). This value comes from new_pw_len = IVAL(lmdata, 512) in chgpasswd.c . I tried hard to find the reason, even with debug level @ 9, I can't :( Same behavior under both 2.2.x and 3.0. I have to admit it was a nice XP (experience) to dig around the source code. Perhaps I need better glasses, LOL! ;-) Thank you, Pierre B.
Re: smbclient 64-bit read/write support, and the lack thereof :-(
Neil, You might want to "download" the latest Samba from CVS. Check out the Web site on how to do this. There has been an issue fixed in late December 2002 (a + 4GB issue) using smbclient. Pierre B. Neil Goldberg wrote: Wondering if anyone knows if it is planned, or if there are patches for large file support in the client side of samba 2.2.x series. I have large files on the windows side that I want to access via smbclient (specifically smbtar), and these fail spectacularly. You can get the filesize of a large file correctly, but all the code that talks to the windows side (cli_*) assumes size is 32-bit, and doesn't seem to be using the newest CIFS protocol. Any advice or suggestions? Neil Goldberg MITRE Corporation PS I am aware the smbfs provides support for large files, but this is linux specific and I am targetting Solaris.
Re: ld Error with solaris 8
Uwe E. Faber wrote: Hi i try to compile samba-2.2.7a on a Solaris 8 System, first i make the ./configure after this i try a make and then i got the error: using LIBS = -lsec -lgen -lsocket -lnsl -ldl Linking bin/smbd ld: fatal: file rpc_server/srv_pipe.o: unknown file type ld: fatal: File processing errors. No output written to bin/smbd collect2: ld returned 1 exit status make: *** [bin/smbd] Error 1 It's not a Samba problem. It is a compiling or linking problem on your box. You should use the "samba" mailing-list, not this list for this issue and add more info to your mail: - which compiler are you using, Sun Workshop / Forte or gcc. which version of the compiler? - which linker , Solaris' or GNU "ld"? - "rm rpc_server/srv_pipe.o" and recompile this file, I don't think this will fix the problem. Try the following command, you should get the following output: # file rpc_server/srv_pipe.o rpc_server/srv_pipe.o: ELF 32-bit MSB relocatable SPARC Version 1 If you use Solaris "ld", make sure you have the latest patches. I don't think it's "ld", I would suspect the compiler. With GCC 2.95.3 using Sun's "ld" I've never had problems compiling Samba. Pierre B.
Re: --with-cracklib (phase 2)
Hello,
Issues & questions:
- Will we ever see more work on cracklib, nothing changed
since 1997. We know we need to add an "API" that doesn't
use "getuid() / getpwuid()". If Alec and/or Chris don't
want to add an API that doesn't use the get{pw}uid(),
we can:
1- Add a patch to cracklib in a "contrib" directory, link
Samba with "libcrack.a"
2- Commit an API in "Samba", still link with "libcrack.a"
for the rest of the functionnalities.
3- Commit a "samba-cracklib" in SAMBA_X_Y , i.e. fully
integrate samba-cracklib in Samba (no more
fprintf(stderr,...), etc), when possible use Samba's
"string" functions instead of cracklib's original.
Don't use sprintf, use Samba's snprintf, etc.
Yes, if cracklib using stdout/stderr as it stands, then we have no
choice but to either isolated it to a 'helper' program, or integrate it
into Samba. I think I prefer integration.
"integration" also means to add at least the "packer" program
needed to create the dictionnary with a "simple" index. Might
as well put them all in .../samba/bin/cracktools/... ???
Well, if we integrate everything, how about "smbcracklib"
or "smb-cracklib" with options to pack, unpack, etc ? Something
like:
Cracklib equiv.
-D Dictionnary path (could be taken from smb.conf ?)
-P pack dictionnary packer
-U unpack dictionnary unpacker
-l test passwords testlib
-d turn on debugging (if needed)
-w print position of a word teststr
-n print word at a specific positiontestnum
I have no preference to what should be included or not, but
the "packer" feature must be included.
[Q] What do you think is the best to do? I don't like #1.
#2 is possible, we'll probably endup with our own re-written
"fascist.c" .
Assuming the license is compatible, then I think this is the best
> course of action.
Is there a "licence Guru" that can give us a confirmation?
The LICENCE is attached in this mail.
I don't see a problem with the following words in the LICENCE:
"plus the right to make reasonable modifications"
We're not going to make that many modifications.
Some "meat" now, not a big piece!
Added the following code in smbd/chgpassword.c ~ line 973 :
#ifdef CRACKLIB
if (msg = NewFascistCheck(new_passwd, CRACKLIB_DICTPATH,
pdb_get_username(hnd), pdb_get_fullname(hnd))) {
DEBUG(0, ("Can't change password - "
"Cracklib returns: %s\n", msg));
return NT_STATUS_ACCESS_DENIED;
/*return NT_STATUS_PASSWORD_RESTRICTION; */
}
}
#endif
[Q] Do we want to be able to configure the dictionnary name
within the smb.conf (char *) or "hard-coded" in cracklib?
Perhaps we want to be able to specify multiple directories
(char **). npasswd uses "(char **)" (mutliple). I have
no preference.
Given the number of platforms we run on, then configuring the dictionary
name would be 'a good idea'. I don't see the need for multiple
dictionaries.
I agree on both of your comments.
[Q] Is NT_STATUS_ACCESS_DENIED the right value to return
when "cracklib" "finds the password" in the dictionary?
No, we should match what NT returns. You figure this out by grabbing
CVS ethereal, and decoding the password change.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mschap/mschap/mschapsrvchangepassword.asp
Gives you a good idea what MS's internal functions do here - and this
maps quite well to the wire actually.
In this case NT_STATUS_PASSWORD_RESTRICTION would be a good choice.
Thanx for the info.
[Q] Is it possible to send back a real message? It could
be "The specified password is invalid. Please choose
a password not based on a dictionnary word" or
"password not long enough - minimum X characters", etc.
It's not possible, the protocol just doesn't have a place for it. :-(.
Too bad ;-) How about trying to send a "POPUP" Window on the Windows
machine? I guess it's possible if the user is already logged in,
but if the user is not logged in yet, i.e. I'm talking about the
situation when you first boot up your computer and you're forced
to change your password *NOW* before you can actually "login"
on the network.
When I change my password here @ work (with a Windows
backend domain controller), I can't take any of my
previous ~ 3 passwords. I do get an "understand" error
message. Is everything needed to send back a "good"
error message already in Samba? If so, how? if not,
well I might need to install a good sniffer and read
a few more documents to understand "windows protocol"
unless someone here already knows how to do this.
I would like to see what it's doing - grab CVS ethereal and decode the
password change, see what goes where.
Will do once cracklib is ready to be integrated. I think I do have
plenty of work to do now ;-)
It's quite possib
Re: --with-cracklib (phase 2)
[Q] Do we want to be able to configure the dictionnary name within the smb.conf (char *) or "hard-coded" in cracklib? Perhaps we want to be able to specify multiple directories (char **). npasswd uses "(char **)" (mutliple). I have no preference. I forgot to mention the following info: - cracklib-original (Alec): the path is hard-coded and supports 1 dictionnary. - npasswd is not hard-coded and supports multiple directories. Voila! Pierre B.
--with-cracklib (phase 2)
Hi,
Here's what I've done so far:
- Added a simple API in cracklib for Samba, works great.
- Sent an email to Alec Muffett, author of cracklib asking
him if he can add this new API that doesn't use
"getuid() & getpwuid()".
- Sent an email to Chris Hoover, author of "npasswd" asking
him a few questions about his work and also if he could
add the new "API" in the npasswd's cracklib distribution.
Note: npasswd's cracklib is modified to do a much better
check (mangle). He added some code from "Crack"
which Alec never added in cracklib. npasswd's new
cracklib "API" does not use getuid / getpwuid which
is what we need but it doesn't check againts the
username & fullusername info. I think this is really
important.
Issues & questions:
- Will we ever see more work on cracklib, nothing changed
since 1997. We know we need to add an "API" that doesn't
use "getuid() / getpwuid()". If Alec and/or Chris don't
want to add an API that doesn't use the get{pw}uid(),
we can:
1- Add a patch to cracklib in a "contrib" directory, link
Samba with "libcrack.a"
2- Commit an API in "Samba", still link with "libcrack.a"
for the rest of the functionnalities.
3- Commit a "samba-cracklib" in SAMBA_X_Y , i.e. fully
integrate samba-cracklib in Samba (no more
fprintf(stderr,...), etc), when possible use Samba's
"string" functions instead of cracklib's original.
Don't use sprintf, use Samba's snprintf, etc.
[Q] What do you think is the best to do? I don't like #1.
#2 is possible, we'll probably endup with our own re-written
"fascist.c" .
Some "meat" now, not a big piece!
Added the following code in smbd/chgpassword.c ~ line 973 :
#ifdef CRACKLIB
if (msg = NewFascistCheck(new_passwd, CRACKLIB_DICTPATH,
pdb_get_username(hnd), pdb_get_fullname(hnd))) {
DEBUG(0, ("Can't change password - "
"Cracklib returns: %s\n", msg));
return NT_STATUS_ACCESS_DENIED;
/*return NT_STATUS_PASSWORD_RESTRICTION; */
}
}
#endif
[Q] Do we want to be able to configure the dictionnary name
within the smb.conf (char *) or "hard-coded" in cracklib?
Perhaps we want to be able to specify multiple directories
(char **). npasswd uses "(char **)" (mutliple). I have
no preference.
As you probably all know, I'm no Windows protocol guru!
[Q] Is NT_STATUS_ACCESS_DENIED the right value to return
when "cracklib" "finds the password" in the dictionary?
[Q] Is it possible to send back a real message? It could
be "The specified password is invalid. Please choose
a password not based on a dictionnary word" or
"password not long enough - minimum X characters", etc.
When I change my password here @ work (with a Windows
backend domain controller), I can't take any of my
previous ~ 3 passwords. I do get an "understand" error
message. Is everything needed to send back a "good"
error message already in Samba? If so, how? if not,
well I might need to install a good sniffer and read
a few more documents to understand "windows protocol"
unless someone here already knows how to do this.
Any other comments are welcome.
Thank you *very much* - enjoy the weekend.
Pierre B.
Re: --with-cracklib for Samba
Hi,
I need "expert" comments on the following, it's "kind of"
related to "cracklib". I could dig another 3 hours in the
code but I prefer to keep that 3 hours for cracklib ;-)
- rpc_server/srv_samr_nt.c line ~ 2836 & line ~ 2898 :
/* update the UNIX password */
if (lp_unix_password_sync() )
if(!chgpasswd(pdb_get_username(pwd), "",
plaintext_buf, True)) {
pdb_free_sam(&pwd);
return False;
}
}
ZERO_STRUCT(plaintext_buf);
if(!pdb_update_sam_account(pwd)) {
pdb_free_sam(&pwd);
return False;
}
[Q] can't we use change_oem_password()?
From smbd/chgpasswd.c line ~ 986. The only big
difference is the IS_SAM_UNIX_USER plus the
"become_root()" before calling pdb_update_sam_account().
[ My previous words is what I'd need to dig into... ]
if(lp_unix_password_sync() && IS_SAM_UNIX_USER(hnd)
&& !chgpasswd(pdb_get_username(hnd),
old_passwd, new_passwd, False)) {
return NT_STATUS_ACCESS_DENIED;
}
if (!pdb_set_plaintext_passwd (hnd, new_passwd)) {
return NT_STATUS_ACCESS_DENIED;
}
/* Now write it into the file. */
become_root();
ret = pdb_update_sam_account (hnd);
unbecome_root();
If we can use change_oem_password() in
rpc_server/srv_samr_nt.c
then I guess we can also remove the following from
smbd/chgpasswd.c ~ line 492 in chgpasswd() since we
already check for this in change_oem_password() :
/* Take the passed information and test it for minimum criteria */
/* Minimum password length */
if (strlen(newpass) < lp_min_passwd_length()) {
/* too short, must be at least MINPASSWDLENGTH */
DEBUG(0, ("Password Change: user %s, New password is shorter"
"than minimum password length = %d\n",
name, lp_min_passwd_length()));
return (False); /* inform the user */
}
If we can't use it, is it because we want to skip the
account_policy_get() in change_oem_password()? I'd also
like to move from smbd/chgpasswd.c line 501 in chgpasswd()
/* Password is same as old password */
if (strcmp(oldpass, newpass) == 0) {
to change_oem_password , so all "check / policy to change
passwords would call from the same place".
I hope I was clear enough, "excuse my French!!". No need
to answer me today on this.
Thank you very much,
Pierre B.
--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.
profile/profile.c bug under (at least) Solaris - 3.0alpha??
Hello Andrew,
I'm sending it "To:" you because I found the following message
on the mailing list:
http://lists.samba.org/pipermail/samba/2002-October/082150.html
The following is true at least under Solaris (all releases) and
perhaps other OS? Linux is probably not affected???
Here's the "bug":
- smbd reports :
Jan 14 11:55:56 carnaval smbd[23609]: [ID 702911 daemon.error]
ERROR: we did not create the shmem (owned by another user)
Jan 14 11:55:56 carnaval smbd[23609]: [ID 702911 daemon.error]
ERROR: failed to setup profiling
Here's the reason why, at least under Solaris:
% grep root /etc/passwd
root:x:0:1:Super-User:/:/sbin/sh
root gid is 1 under Solaris (group named "other).
In smbd/server.c , here's how it runs...
line # 668 : sec_init(); , which does:
initial_uid = geteuid();
initial_gid = getegid();
line # 693:
gain_root_privilege();
gain_root_group_privilege();
Set uid/gid/egid/euid to 0.
line # 751:
if (!profile_setup(False)) {
DEBUG(0,("ERROR: failed to setup profiling\n"));
return -1;
In profile/profile.c
line # 139
if (shm_ds.shm_perm.cuid != sec_initial_uid() ||
shm_ds.shm_perm.cgid != sec_initial_gid()) {
DEBUG(0,("ERROR: we did not create the shmem (owned by ...
So...
"gain_root_group_privilege" does setegid/setgid to 0.
When profile/profile.c line #139 checks the gid who
created the shared memory, shm_ds.shm_perm.cgid = 0
BUT sec_initial_gid() returns 1. So, smbd complains
that it did not create the shared memory.
I propose the following changes to profile/profile.c, see
attached diff file againts SAMBA_3_0. I added a check for
"EEXIST" after creating the shared memory. This could? fix
the race condition if shmget is "atomic". No notes on this
under Solaris. I also don't know if EEXIST exists on "all"
OS. Up to you to add it in there or not.
Another "tiny" bug line ~ # 130 in profile/profile.c (it's
fixed in my diff). Also needs to be fixed in SAMBA_2_2 and
HEAD:
--- if ((long)profile_p == -1) {
+++ if ((long)profile_h == -1) {
Fell free to make moifications to my patch, I do welcome
negative/positive comments ;-)
Cheers,
Pierre B.
--- profile/profile.c.orig Tue Jan 14 13:37:18 2003
+++ profile/profile.c Tue Jan 14 14:24:01 2003
@@ -106,24 +106,38 @@
/* try to use an existing key */
shm_id = shmget(PROF_SHMEM_KEY, 0, 0);
- /* if that failed then create one. There is a race condition here
- if we are running from inetd. Bad luck. */
+ /* if that failed then create one. */
if (shm_id == -1) {
+
+ static BOOL redo = True;
+
if (read_only) return False;
shm_id = shmget(PROF_SHMEM_KEY, sizeof(*profile_h),
IPC_CREAT | IPC_EXCL | IPC_PERMS);
- }
-
- if (shm_id == -1) {
- DEBUG(0,("Can't create or use IPC area. Error was %s\n",
-strerror(errno)));
- return False;
+
+ if (shm_id == -1) {
+
+ /* Check if we might have run into a race condition when
+running
+ from inetd. Bad luck. */
+ if ((errno == EEXIST) && (redo == True)) {
+
+ /* Make sure we don't spin forever - prevent OS bug */
+ redo = False;
+ DEBUG(0,("Can't create or use IPC area. Error was
+%s\n",
+strerror(errno)));
+ DEBUG(0,("Trying again to use IPC area.\n"));
+ goto again;
+ } else {
+ DEBUG(0,("Can't create or use IPC area. Error was
+%s\n",
+strerror(errno)));
+ return False;
+ }
+ }
}
-
profile_h = (struct profile_header *)shmat(shm_id, 0,
read_only?SHM_RDONLY:0);
- if ((long)profile_p == -1) {
+ if ((long)profile_h == -1) {
DEBUG(0,("Can't attach to IPC area. Error was %s\n",
strerror(errno)));
return False;
@@ -136,8 +150,13 @@
return False;
}
- if (shm_ds.shm_perm.cuid != sec_initial_uid() || shm_ds.shm_perm.cgid !=
sec_initial_gid()) {
+ if (shm_ds.shm_perm.cuid != getuid()) {
DEBUG(0,("ERROR: we did not create the shmem (owned by another
user)\n"));
+ return False;
+ }
+
+ if (shm_ds.shm_perm.cgid != getgid()) {
+ DEBUG(0,("ERROR: we did not create the shmem (owned by another
+group)\n"));
return False;
}
Re: Problem with utmp under Solaris
Hi, I found the following message (June 2002). http://lists.samba.org/pipermail/samba-technical/2002-June/037434.html I read the whole thread. Any new comments? I will try to find a solution from what I read unless there are new ideas? Thanx to google and sorry not to search on google before posting here. Pierre B. Pierre Belanger wrote: > > Hi, > > I found the following problem under Solaris (8) when > enabling "utmp = yes". "last" is ok, but not "finger". > > # last > livetan smb/9 10.64.3.241 Mon Dec 2 09:01 still logged in > vassile smb/8 10.64.3.84 Mon Dec 2 09:01 still logged in > > # finger > finger: Can't stat /dev/smb/8 ... and "finger" dies right away. > > There's no "/dev/smb/..." under Solaris. I haven't searched > a lot for a solution. > > Pierre B.
Problem with utmp under Solaris
Hi, I found the following problem under Solaris (8) when enabling "utmp = yes". "last" is ok, but not "finger". # last livetan smb/9 10.64.3.241 Mon Dec 2 09:01 still logged in vassile smb/8 10.64.3.84 Mon Dec 2 09:01 still logged in # finger finger: Can't stat /dev/smb/8 ... and "finger" dies right away. There's no "/dev/smb/..." under Solaris. I haven't searched a lot for a solution. Pierre B.
use sendfile loadparm.c / docs inconsistency
Hi,
[ Yeah, me again about this sendfile stuff ;-) ]
I notice some inconsistence in the documentations...
"smb.conf.5" is listing "use sendfile" in the
"COMPLETE LIST OF GLOBAL PARAMETERS"
area, and later in the same manual, it shows
"use sendfile" has a "shared parameter":
"use sendfile (S)"
I think this parameter should be moved from
the "COMPLETE LIST OF GLOBAL PARAMETERS" to
"COMPLETE LIST OF SERVICE PARAMATERS".
I also notice in param/loadparm.c :
{"use sendfile", P_BOOL, P_LOCAL,
&sDefault.bUseSendfile, NULL, NULL, FLAG_SHARE},
ps: Is there really a need to control "use sendfile"
per share? I don't see one, if sendfile is working
why not turn it on... that's my opinion!
Anyhow, I think the FLAG_GLOBAL is missing?!?!
Thank you,
Pierre B.
__
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
sendfile profiling patch for utils/status.c
Hello all,
I'm including a "tiny patch" for utils/status.c , in
diff -u format ... Hope I did this right!
After applying the patch...
# ./bin/smbstatus -P
{snip}
read_bytes: 0
write_count:1
write_time: 166
write_bytes:54
sendfile_count: 4
sendfile_time: 16262
sendfile_bytes: 20480
lseek_count:2
lseek_time: 18
rename_count: 0
{snip}
The patch is attached in the mail. Fell free to all the
required "printf" where I add them, after the write_bytes,
or anywhere else...
Thank you,
Pierre B.
--- utils/status.c Mon Aug 26 12:08:01 2002
+++ utils/status.c.new Thu Oct 3 09:50:19 2002
@@ -194,6 +194,11 @@
printf("write_count:%u\n", profile_p->syscall_write_count);
printf("write_time: %u\n", profile_p->syscall_write_time);
printf("write_bytes:%u\n", profile_p->syscall_write_bytes);
+#ifdef HAVE_SENDFILE
+ printf("sendfile_count:%u\n",
+profile_p->syscall_sendfile_count);
+ printf("sendfile_time: %u\n",
+profile_p->syscall_sendfile_time);
+ printf("sendfile_bytes:%u\n",
+profile_p->syscall_sendfile_bytes);
+#endif
printf("lseek_count:%u\n", profile_p->syscall_lseek_count);
printf("lseek_time: %u\n", profile_p->syscall_lseek_time);
printf("rename_count: %u\n",
profile_p->syscall_rename_count);
