From cartegw at Eng.Auburn.EDU Tue Jun 1 02:43:39 1999 From: cartegw at Eng.Auburn.EDU (Gerald Carter) Date: Tue Dec 2 03:03:04 2003 Subject: SMB password encryption Message-ID: <375348DB.1A95C955@eng.auburn.edu> Good evening (at least it is here), I need a reference for LanMan and NT password encryption as implemented in SMB. Can someone point out an official document (if such a thing exists) that could be used in the references section of a paper? Other then the Samba source code and associated docs of course. Cheers, jerry ________________________________________________________________________ Gerald ( Jerry ) Carter Engineering Network Services Auburn University jerry@eng.auburn.edu http://www.eng.auburn.edu/users/cartegw "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" ( 1979 ) From danny at cs.huji.ac.il Tue Jun 1 13:07:04 1999 From: danny at cs.huji.ac.il (Danny Braniss) Date: Tue Dec 2 03:03:04 2003 Subject: NetAPP/CIFS and samba Message-ID: hello all, im running samba 2.0.4b, and it's doing ok as a PDC. but i can't get my netapp(Release 5.1.2) to use it. is there some magic that im missing? tia, danny From kyhm at mars.ark.com Tue Jun 1 15:25:04 1999 From: kyhm at mars.ark.com (Morgan Hughes) Date: Tue Dec 2 03:03:04 2003 Subject: is smbrun(1) used anymore? Message-ID: Looking at the code in lib/smbrun.c suggests that the smbrun wrapper program is a vestigal organ... Can anyone confirm this? I've been having trouble with preexec and postexec (root and non), and the debug code I added to the wrapper never runs... In lib/smbrun.c, it seems that most of the functionality of the wrapper has been moved into the smbrun() function... -- Morgan Hughes C programmer and highly caffeinated mammal kyhm@mars.ark.com -- If at first you don't succeed, redefine success. From lkcl at switchboard.net Tue Jun 1 15:59:57 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:04 2003 Subject: LDAP support sucks big time In-Reply-To: <19990531103322.D23315@callisto.rug.ac.be> Message-ID: http://samba.org/cvs.html. obtain and use latest cvs. On Mon, 31 May 1999, Piet Ruyssinck wrote: > Hello, > > I just subscribed to this mailing list primarily as a means to vent my > frustration regarding the so called LDAP support in the samba-2.0.4b > source tree. This 'code' is a big joke, full of syntax errors even. > It is completely unuseable and had better been removed from the > distribution. > > Since I badly need LDAP support, the only thing I can do is rewrite the > code myself. I was wondering if the 'API' by which the 'modules' in > samba-2.0.4b/source/passdb are plugged into the rest of the code is a > static one or whether it is still being changed from release to release > ? It would be nice to know that I don't have to revise my code with > every new release of Samba. And while I'm on the topic, there wouldn't > happen to be a document available describing this API, would it ? > > -- > -------------------------------------------------------- > Piet RUYSSINCK Piet.Ruyssinck@rug.ac.be > Unix Systeem Administratie +32 9 264 4733 > ACADEMISCH REKENCENTRUM (ARC) Universiteit Gent (RUG) > Krijgslaan 281, gebouw S9, bureel 4 9000 Gent, Belgie > > Luke Kenneth Casson Leighton Samba and Network Development Samba Web site ===================================================================== Luke Kenneth Casson Leighton | Direct Dial : (678) 443-6183 Systems Engineer / ISS XForce Team | ISS Front Desk: (678) 443-6000 Internet Security Systems, Inc. | ISS Fax : (678) 443-6477 http://www.iss.net/ *Adaptive Network Security for the Enterprise* ISS Connect - International User Conference - May '99 ===================================================================== From lkcl at switchboard.net Tue Jun 1 16:12:25 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:04 2003 Subject: SMB password encryption In-Reply-To: <375348DB.1A95C955@eng.auburn.edu> Message-ID: i've not actually heard of any: there used to be some on ftp://ftp.microsoft.com/developr/drg/CIFS at least two years ago, but not any more (i looked 6 weeks ago). luke On Tue, 1 Jun 1999, Gerald Carter wrote: > Good evening (at least it is here), > > I need a reference for LanMan and NT password encryption > as implemented in SMB. Can someone point out an official > document (if such a thing exists) that could be used in > the references section of a paper? Other then the Samba > source code and associated docs of course. > > > > Cheers, > jerry > ________________________________________________________________________ > Gerald ( Jerry ) Carter > Engineering Network Services Auburn University > jerry@eng.auburn.edu http://www.eng.auburn.edu/users/cartegw > > "...a hundred billion castaways looking for a home." > - Sting "Message in a Bottle" ( 1979 ) > Luke Kenneth Casson Leighton Samba and Network Development Samba Web site ===================================================================== Luke Kenneth Casson Leighton | Direct Dial : (678) 443-6183 Systems Engineer / ISS XForce Team | ISS Front Desk: (678) 443-6000 Internet Security Systems, Inc. | ISS Fax : (678) 443-6477 http://www.iss.net/ *Adaptive Network Security for the Enterprise* ISS Connect - International User Conference - May '99 ===================================================================== From lkcl at switchboard.net Tue Jun 1 16:14:01 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:04 2003 Subject: SMB password encryption In-Reply-To: <375348DB.1A95C955@eng.auburn.edu> Message-ID: hang on, yes there is: open solution providers. http://www.osp.nl/infobase/ntpass.html. On Tue, 1 Jun 1999, Gerald Carter wrote: > Good evening (at least it is here), > > I need a reference for LanMan and NT password encryption > as implemented in SMB. Can someone point out an official > document (if such a thing exists) that could be used in > the references section of a paper? Other then the Samba > source code and associated docs of course. > > > > Cheers, > jerry > ________________________________________________________________________ > Gerald ( Jerry ) Carter > Engineering Network Services Auburn University > jerry@eng.auburn.edu http://www.eng.auburn.edu/users/cartegw > > "...a hundred billion castaways looking for a home." > - Sting "Message in a Bottle" ( 1979 ) > Luke Kenneth Casson Leighton Samba and Network Development Samba Web site ===================================================================== Luke Kenneth Casson Leighton | Direct Dial : (678) 443-6183 Systems Engineer / ISS XForce Team | ISS Front Desk: (678) 443-6000 Internet Security Systems, Inc. | ISS Fax : (678) 443-6477 http://www.iss.net/ *Adaptive Network Security for the Enterprise* ISS Connect - International User Conference - May '99 ===================================================================== From Jean-Francois.Micouleau at dalalu.fr Wed Jun 2 05:35:06 1999 From: Jean-Francois.Micouleau at dalalu.fr (Jean Francois Micouleau) Date: Tue Dec 2 03:03:04 2003 Subject: CVS update: samba/source/smbd In-Reply-To: <19990602041156Z12861742-4203+8@samba.anu.edu.au> Message-ID: On Wed, 2 Jun 1999, Matt Chapman wrote: > Log Message: > Fixing core dump bug with unix password sync, caused by a NULL > connection_struct in a call to OpenDir. > JF, you fixed a similar bug in printing/nt_printing.c, I think your fix > is incorrect as global configuration files should not go through a VFS. well, I wrote that code before the vfs stuff. But I totally agree with you, samba internal file access shoudn't go through the VFS. It's not the only place where VFS code is used on samba "private" files. Who's gone fix it ??? J.F. From Tim.Potter at anu.edu.au Wed Jun 2 05:45:05 1999 From: Tim.Potter at anu.edu.au (Tim Potter) Date: Tue Dec 2 03:03:04 2003 Subject: CVS update: samba/source/smbd In-Reply-To: References: <19990602041156Z12861742-4203+8@samba.anu.edu.au> Message-ID: <14164.50401.607930.778812@acronym.anu.edu.au> Jean Francois Micouleau writes: > > Fixing core dump bug with unix password sync, caused by a NULL > > connection_struct in a call to OpenDir. > > JF, you fixed a similar bug in printing/nt_printing.c, I think your fix > > is incorrect as global configuration files should not go through a VFS. > > well, I wrote that code before the vfs stuff. But I totally agree with > you, samba internal file access shoudn't go through the VFS. > > It's not the only place where VFS code is used on samba "private" files. > Who's gone fix it ??? You can fix it yourself, or tell me and I'll do it. I thought I was pretty careful in weeding out improper uses of the VFS code when writing it. Tim. > > J.F. > -- Tim Potter, System Admin/Programmer, Head Bee Guy Advanced Computational Systems CRC, RSISE Bldg Australian National University, Canberra 0200, AUSTRALIA Ph: +61 2 62798813 Fax: +61 2 62798602 From sbuente at kw-software.de Wed Jun 2 10:02:31 1999 From: sbuente at kw-software.de (Sven =?iso-8859-1?Q?B=FCnte?=) Date: Tue Dec 2 03:03:04 2003 Subject: Missing option Message-ID: <3.0.5.32.19990602190231.00847ad0@mail.adelaide.on.net> Dear Mr. Sharpe! I'm currently using samba 2.0.3, and I miss a nice feature of earlier versions, may be you can help me: I wanted to look, which files a special machine accessed (reading or writeing) yesterday. So in the log-files I did not found anything about this. So I wrote a file to a share and looked again for the filename in the log-files. I've found nothing, even when switching to debug-level 10. But instead of this, even in debug-level 0 I found a lot of (for me) useless information of the smbd-server (like user xy has connected to a service, connection closed...). Can you tell me, is it possible to create such log-files like xferlog? If yes, how? I did not found anything in the whole documentation. If this is not possible, you (or someone else) should implement such a feature. I think it would be very important to be able to track the user-accesses. Another feature you may implement in future versions: The smb.conf file should give better control of how to access files and subdirectories of a share, in the style of apache config-files. Even the ProFTP-Daemon does this, and it is possible for example to deny writing in one directory and deny reading in another or faking to other uids in another dir. Because these ***-Windoze-stations are not able to handle unix-user-rights. With best regards, Sven Buente From cartegw at Eng.Auburn.EDU Wed Jun 2 13:54:06 1999 From: cartegw at Eng.Auburn.EDU (Gerald W. Carter) Date: Tue Dec 2 03:03:04 2003 Subject: is smbrun(1) used anymore? References: Message-ID: <3755377E.3DC8DB42@eng.auburn.edu> Morgan Hughes wrote: > > Looking at the code in lib/smbrun.c suggests that > the smbrun wrapper program is a vestigal organ... > Can anyone confirm this? I've been having trouble > with preexec and postexec (root and non), and the debug > code I added to the wrapper never runs... In > lib/smbrun.c, it seems that most of the functionality > of the wrapper has been moved into the smbrun() > function... If I remember correctly, smbrun is used in systems that do not have execlp() (? one of the exec..() functions...not sure if this is the exact one or not) Cheers, jerry ________________________________________________________________________ Gerald ( Jerry ) Carter Engineering Network Services Auburn University jerry@eng.auburn.edu http://www.eng.auburn.edu/users/cartegw "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" ( 1979 ) From matty at samba.org Wed Jun 2 14:11:45 1999 From: matty at samba.org (Matt Chapman) Date: Tue Dec 2 03:03:04 2003 Subject: is smbrun(1) used anymore? References: <3755377E.3DC8DB42@eng.auburn.edu> Message-ID: <37553BA1.DC24D782@samba.org> "Gerald W. Carter" wrote: > > If I remember correctly, smbrun is used in systems that > do not have execlp() (? one of the exec..() functions...not > sure if this is the exact one or not) Yep, it is only compiled and used if execl is not present. Matt -- Matthew "Austin" Chapman SysAdmin, Developer, Samba Team Member "I have a dream... that one day, my three little children will be judged not on the quality of their character, but on the content of their code..." From abakun at reac.com Wed Jun 2 15:22:12 1999 From: abakun at reac.com (Andy Bakun) Date: Tue Dec 2 03:03:04 2003 Subject: Missing option References: <3.0.5.32.19990602190231.00847ad0@mail.adelaide.on.net> Message-ID: <37554C24.A301BD77@reac.com> > Can you tell me, is it possible to create such log-files like xferlog? If > yes, how? I did not found anything in the whole documentation. > If this is not possible, you (or someone else) should implement such a > feature. I think it would be very important to be able to track the > user-accesses. http://www.reac.com/samba/samba-audit.html Some stuff isn't implemented yet, because I don't have a direct need for those things that are not implemented, and there has been little outside interest in getting those features implemented. The main things that are not implemented are auditing of each read and write operation and file permission issues. > Another feature you may implement in future versions: > The smb.conf file should give better control of how to access files and > subdirectories of a share, in the style of apache config-files. Even the > ProFTP-Daemon does this, and it is possible for example to deny writing in > one directory and deny reading in another or faking to other uids in another > dir. Because these ***-Windoze-stations are not able to handle > unix-user-rights. I did this by creating UNIX groups, which is safer anyway, because the permissions file doesn't live in the directory it is protecting. Andy. From lkcl at switchboard.net Wed Jun 2 16:10:22 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:04 2003 Subject: CVS update: samba/source/rpc_parse In-Reply-To: <19990602031917Z12862144-19336+5@samba.anu.edu.au> Message-ID: matt, let's create our own scheme for now, so that at least we can do samba pdc <- samba bdc syncs. any suggestions, anyone? On Wed, 2 Jun 1999, Matt Chapman wrote: > > Date: Wednesday June 2, 1999 @ 13:19 > Author: matty > > Update of /data/cvs/samba/source/rpc_parse > In directory samba:/data/people/matty/samba/source/rpc_parse > > Modified Files: > parse_net.c > Log Message: > Some more BDC-related fixes, mainly to the NET_SAM_SYNC RPC with respect > to alignment, missing fields, etc. - it should now work correctly. > There is still the problem of decoding the private data field. > > Luke Kenneth Casson Leighton Samba and Network Development Samba Web site ===================================================================== Luke Kenneth Casson Leighton | Direct Dial : (678) 443-6183 Systems Engineer / ISS XForce Team | ISS Front Desk: (678) 443-6000 Internet Security Systems, Inc. | ISS Fax : (678) 443-6477 http://www.iss.net/ *Adaptive Network Security for the Enterprise* ISS Connect - International User Conference - May '99 ===================================================================== From kyhm at mars.ark.com Wed Jun 2 19:55:14 1999 From: kyhm at mars.ark.com (Morgan Hughes) Date: Tue Dec 2 03:03:04 2003 Subject: is smbrun(1) used anymore? In-Reply-To: <37553BA1.DC24D782@samba.org> Message-ID: > > If I remember correctly, smbrun is used in systems that > > do not have execlp() (? one of the exec..() functions...not > > sure if this is the exact one or not) > Yep, it is only compiled and used if execl is not present. Yup, ok, mea culpa ;-) I must've missed or misunderstood the #ifndef HAVE_EXECL. -- Morgan Hughes C programmer and highly caffeinated mammal kyhm@mars.ark.com -- Hit any user to continue. From Mattias.Gronlund at sa.erisoft.se Wed Jun 2 21:22:11 1999 From: Mattias.Gronlund at sa.erisoft.se (Mattias.Gronlund) Date: Tue Dec 2 03:03:04 2003 Subject: RFE: Better logging Message-ID: <3755A083.B02B037F@sa.erisoft.se> Hi, I administrate three SUN-servers which have >500 clients connected we have had som problems with Samba from time to time. The current release seems very stable, but we still need an improved log-files to find all the bugs. I'm not saying that the current logging is bad (havent seen much better), but there is still some improvments that I think could be done. 1. For sites with lots of clients you don't allways whant to split the log into one log per client. But you still whant to be able to identify which messages relates to which machine. There may even be intresting to see which process they relate to if it is a multiuser client whith one smbd per user. My proposal is to add a process-ID attribute to the log-header and to write one level 0 message whenever a new process forks. 2. We have had some problems with "Slow network detected" and was able to track it down and implement a "hack" that was reported and the "Samba team" was able to implement a nice patch. The tool we used was an extra microsecond attribute in the log- header. The current implementation a cached time to the header, it may be write a time stamp at least one second wrong. 3. Before we installed version 2 of samba we had some strange "Failed to set socket option" entrys in our log, they appeared infrequently but they where there. Sadly enought the log-entry didn't specify errno so we had a hard time debugging it any futher. Our problem at the time is that we are running Samba in full production an we can't even "restart" samba other then one weekend a month or we get lots of Netscape crashes and who knows what else, so we are extreamly log-dependent for debugging... I will include some "hack" patches that might explain what I would like. If it they will get better acceptance I'm more then willing to clean them up. BTW: Thanks for an Extreamly stable and debuggable product! Regard Mattias -------------- next part -------------- --- lib/time.c.orig Tue May 25 14:14:30 1999 +++ lib/time.c Wed Jun 2 23:13:41 1999 @@ -509,16 +509,19 @@ char *timestring(void ) { static fstring TimeBuf; - time_t t = time(NULL); - struct tm *tm = LocalTime(&t); - + struct timeval tp; + struct tm *tm; + GetTimeOfDay(&tp); + + tm = LocalTime(&(time_t)tp.tv_sec); if (!tm) { - slprintf(TimeBuf,sizeof(TimeBuf)-1,"%ld seconds since the Epoch",(long)t); + slprintf(TimeBuf,sizeof(TimeBuf)-1,"%ld.%06ld seconds since the Epoch",(long)tp.tv_sec, (long)tp.tv_usec); } else { #ifdef HAVE_STRFTIME - strftime(TimeBuf,100,"%Y/%m/%d %H:%M:%S",tm); + strftime(TimeBuf,sizeof(TimeBuf)-1,"%Y/%m/%d %H:%M:%S",tm); + slprintf(TimeBuf+strlen(TimeBuf), sizeof(TimeBuf)-1 - strlen(TimeBuf), ".%06ld", (long)tp.tv_usec); #else - fstrcpy(TimeBuf, asctime(tm)); + slprintf(TimeBuf, sizeof(TimeBuf)-1, "%s.%06ld", asctime(tm), (long)tp.tv_usec); #endif } return(TimeBuf); --- smbd/server.c.old Wed Apr 28 23:44:59 1999 +++ smbd/server.c Wed Jun 2 22:58:19 1999 @@ -232,7 +232,8 @@ descriptors */ close_low_fds(); am_parent = 0; - + + DEBUG(0, ("open_sockets: Recieved new connection")); set_socket_options(Client,"SO_KEEPALIVE"); set_socket_options(Client,user_socket_options); --- lib/debug.c.orig Tue May 25 14:14:34 1999 +++ lib/debug.c Tue May 25 14:22:53 1999 @@ -544,8 +544,8 @@ if( lp_timestamp_logs() || !(lp_loaded()) ) { /* Print it all out at once to prevent split syslog output. */ - (void)Debug1( "[%s, %d] %s:%s(%d)\n", - timestring(), level, file, func, line ); + (void)Debug1( "[%s, %d, %d] %s:%s(%d)\n", + timestring(), level, getpid(), file, func, line ); } return( True ); --- lib/util_sock.c.orig Tue May 18 00:28:11 1999 +++ lib/util_sock.c Tue May 25 14:25:48 1999 @@ -152,7 +152,8 @@ } if (ret != 0) - DEBUG(0,("Failed to set socket option %s\n",tok)); + DEBUG(0,("Failed to set socket option %s, %s\n", + tok,strerror(errno))); } } From cartegw at Eng.Auburn.EDU Thu Jun 3 03:36:31 1999 From: cartegw at Eng.Auburn.EDU (Gerald Carter) Date: Tue Dec 2 03:03:04 2003 Subject: HPUX 10.20 Message-ID: <3755F83F.D3242E1@eng.auburn.edu> Can anyone remember of there are any issues with HPUX regarding the guest account and browsing a server? Other than the normal configuration ones of course? I mean is there anythgin HPUX specific? Thanks, jerry ________________________________________________________________________ Gerald ( Jerry ) Carter Engineering Network Services Auburn University jerry@eng.auburn.edu http://www.eng.auburn.edu/users/cartegw "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" ( 1979 ) From abakun at reac.com Thu Jun 3 19:16:07 1999 From: abakun at reac.com (Andy Bakun) Date: Tue Dec 2 03:03:05 2003 Subject: conversion to 8.3 might be broken in 2.0.4 Message-ID: <3756D476.6E50B305@reac.com> I've got some directories that contain a number of other directories whose names are all 9 digits long. Here's the output of dir /X (the /X option shows 8.3 filenames) for one of the directories: f:\sdf1\stage2\cj02>dir /X Volume in drive F is archiveclean Volume Serial Number is 156A-70DD Directory of f:\sdf1\stage2\cj02 06/01/99 02:28p . 06/03/99 01:00p .. 06/03/99 12:59p 19950~2Z 199500579 06/03/99 12:59p 19950~!9 199500586 06/03/99 12:59p 19950~I- 199500630 06/03/99 12:59p 19950~OZ 199500631 06/03/99 12:59p 19950~UX 199500632 06/03/99 12:59p 19950~_V 199500633 06/03/99 12:59p 19950~XW 199500641 06/03/99 12:59p 19950~8Q 199500646 05/27/99 04:45p 19950~I- 199500653 06/03/99 12:59p 19950~HN 199500654 06/03/99 12:59p 19950~ZH 199500659 06/03/99 12:59p 19950~@U 199500661 06/03/99 12:59p 19950~L_ 199500662 06/03/99 12:59p 19950~RY 199500663 06/03/99 12:59p 19950~EO 199500664 05/27/99 04:45p 19950~XW 199500687 06/03/99 12:59p 19950~DA 199500688 06/03/99 12:59p 19950~7C 199500689 06/03/99 12:59p 19950~5R 199500690 06/03/99 12:59p 19950~OZ 199500694 05/27/99 04:46p 19950~I- 199500695 06/03/99 12:59p 19950~_V 199500696 06/03/99 12:59p 19950~A4 199500704 06/03/99 12:59p 19950~M0 199500706 06/03/99 12:59p 19950~!9 199500712 06/03/99 12:59p 19950~TC 199500721 06/03/99 12:59p 19950~M0 199500727 06/03/99 12:59p 19950~X@ 199500729 06/03/99 12:59p 19950~WB 199500732 06/03/99 12:59p 19950~75 199500735 06/03/99 12:59p 19950~J1 199500737 05/27/99 04:47p 19950~$8 199500740 06/03/99 12:59p 19950~ZA 199500741 06/03/99 12:59p 19950~NE 199500743 06/03/99 12:59p 19950~2Z 199500748 06/03/99 12:59p 19950~!9 199500750 06/03/99 12:59p 19950~$8 199500761 06/03/99 12:59p 19950~TC 199500763 06/03/99 12:59p 19950~46 199500766 06/03/99 12:59p 19950~@- 199500768 05/27/99 04:48p 19950~%_ 199500779 06/03/99 12:59p 19950~A4 199500780 06/03/99 12:59p 19950~M0 199500782 06/03/99 12:59p 19950~G2 199500783 06/03/99 12:59p 19950~EV 199500788 06/03/99 01:00p 19950~!9 199500796 06/03/99 01:00p 19950~_V 199500801 06/03/99 01:00p 19950~BP 199500825 06/03/99 01:00p 19950~1E 199500838 06/03/99 01:00p 19950~TJ 199500849 06/03/99 01:00p 19950~XW 199500852 05/27/99 04:49p 19950~2S 199500854 06/03/99 01:00p 19950~EO 199500856 06/03/99 01:00p 19950~I- 199500861 06/03/99 01:00p 19950~UX 199500863 06/03/99 01:00p 19950~%T 199500865 06/03/99 01:00p 19950~L_ 199500871 06/03/99 01:00p 19950~@U 199500872 06/03/99 01:00p 19950~WI 199500878 06/03/99 01:00p 19950~QK 199500879 06/03/99 01:00p 19950~BP 199500880 06/03/99 01:00p 19950~HN 199500881 06/03/99 01:00p 19950~I- 199500886 06/03/99 01:00p 19950~M7 199500889 06/03/99 01:00p 19950~EO 199500890 06/03/99 01:00p 19950~KM 199500891 06/03/99 01:00p 19950~17 199500906 06/03/99 01:00p 19950~QD 199500941 06/03/99 01:00p 19950~WB 199500942 06/03/99 01:00p 19950~$8 199500953 06/03/99 01:00p 19950~O% 199500969 06/03/99 01:00p 19950~X@ 199500978 06/03/99 01:00p 19950~D3 199500980 06/03/99 01:00p 19950~75 199500983 06/03/99 01:00p 19950~0I 199501004 06/03/99 01:00p 19950~6G 199501005 06/03/99 01:00p 19950~CE 199501006 06/03/99 01:00p 19950~0I 199501025 06/03/99 01:00p 19950~X7 199501038 06/03/99 01:00p 19950~YL 199501050 06/03/99 01:00p 19950~MP 199501052 06/03/99 01:00p 19950~-K 199501060 06/03/99 01:00p 19950~IC 199501064 06/03/99 01:00p 19950~CE 199501065 06/03/99 01:00p 19950~%4 199501068 06/03/99 01:00p 19950~-K 199501087 06/03/99 01:00p 19950~B0 199501089 06/03/99 01:00p 19950~9F 199501091 06/03/99 01:00p 19950~DZ 199501106 06/03/99 01:00p 19950~!$ 199501122 06/03/99 01:00p 19950~X0 199501123 06/03/99 01:00p 19950~7- 199501124 06/03/99 01:00p 19950~L4 199501142 95 File(s) 0 bytes 2 147 418 112 bytes free Now, you'll notice that a number of these directories have the same short filename. Using UNIX shell utilities, I count 93 directories, but only 63 unique 8.3 names. Specificly, the directories 199500631 and 199500694 have the same 8.3 filename, also 199500633 and 199500696. Obviously, this is a problem (WinNT apparently gives applications the short filename when you drop a file on an application shortcut). I'm running Samba version 2.0.4a with the 2.0.4b patch applied (plus my other patches, none of which touch the 8.3 generation code as far as I know). Linux jupiter.reac.com 2.0.35 #2 Tue Oct 20 19:46:21 CDT 1998 i686 unknown RedHat 5.1 with a bunch of 5.2 stuff added. glibc-2.0.111-0.990127 glibc-devel-2.0.111-0.990127 Andy. From abakun at reac.com Thu Jun 3 19:49:02 1999 From: abakun at reac.com (Andy Bakun) Date: Tue Dec 2 03:03:05 2003 Subject: FILE: and NE??: files Message-ID: <3756DC2E.96F7F96B@reac.com> In my environment, we print to files a lot in order to post processing before actually sending the output to the printer, and there have been an increasing number of instances where files named FILE: or NE??: (where ?? is a two digit number corresponding to the "network port" that the printer used to print to file is on) are being generated. Note that my WinNT4Sp4 clients always display these files with the 8.3 mangled names (because you can't have a : in a filename in windows, I suspect). These files are either zero bytes long, or actually contain printer output. Unfortunately, my users don't know what makes these files and if the file actually contains something, they just notice that the file they meant to generate doesn't exist and try again. This doesn't happen with every print job, but it does happen. Anyway, while poking around looking for hints as to my previous message about the duplicate 8.3 entries in the same directory, I happened across the function is_reserved_msdos in smbd/mangle.c. Would adding entries to the switch for FILE: and filenames of the form NE??: (where ?? are digits) get rid of this? I figure that the client printer driver is opening a file named FILE:, which is susposed to be caught by the filesystem subsystem in NT but which is somehow getting past that and being sent to samba, which happily creates the file which is susposed to name a port on the local machine. Anyone know about this or have any references? I can write the patch if someone else agrees that what I described is the right thing to do. Andy. From sharpe at ns.aus.com Fri Jun 4 04:48:07 1999 From: sharpe at ns.aus.com (Richard Sharpe) Date: Tue Dec 2 03:03:05 2003 Subject: Any problems with WNT accessing profiles on a Samba 2.0.4b server? Message-ID: <3.0.5.32.19990604134807.00932740@mail.adelaide.on.net> Hi, a collegue of mine in Canada :-) is having some problems with 2.0.4b. He says that these surfaced when he installed 2.0.4b over the top of a working 2.0.3 system. His NT machine, configured as a PDC, is set up to get user profiles from a Samba machine. This Samba 2.0.4b system has: security = DOMAIN encrypt passwords = Yes password server = wired # The NT Machine username map = /usr/local/etc/username.map log file = /var/log/samba/log.%m max log size = 50 socket options = TCP_NODELAY local master = No dns proxy = No wins server = 216.183.4.2 guest account = pcguest logon server = yes # This looks bogus and wrong The NT machine is complaining that it cannot access the profiles and is creating a new set, as far as I can see. Has anyone seen this? Regards ------- Richard Sharpe, sharpe@ns.aus.com, NS Computer Software and Services P/L, Samba (Team member www.samba.org), Ethereal (Team member www.zing.org) Co-author, SAMS Teach Yourself Samba in 24 Hours Author, First Australian Linux Course From pchapman at technical-concepts.co.uk Fri Jun 4 10:35:01 1999 From: pchapman at technical-concepts.co.uk (pchapman@technical-concepts.co.uk) Date: Tue Dec 2 03:03:05 2003 Subject: newbie help Message-ID: Hi all, I am very new to the wonderful world of Samba (I have to keep telling my assistant that its not a south american dance...) and require a little assistance. I have downloaded the latest version of Samba, together with all of the documentation. I have managed to sucessfully untar the files but I am having difficulty compiling the files. I am using SCO Unix and when I type in the ./configure command in the source directory (as per the UNIX INSTALL instructions) I get an error message saying './configure:cant execute' Can anyone help Thanks in advance Peter Chapman From jarod at csee.wvu.edu Fri Jun 4 17:49:07 1999 From: jarod at csee.wvu.edu (Jarod King) Date: Tue Dec 2 03:03:05 2003 Subject: head branch kills printers... Message-ID: <37581193.2308E474@csee.wvu.edu> We're trying to get the head brach to run on a Solaris 2.5.1 box, but after a couple of hours, the printer shares seem to die. As soon as we revert to 1.9, things are fine. Anyone else had similar problems? jarod From lnb at freedom.cybertouch.org Sat Jun 5 05:37:34 1999 From: lnb at freedom.cybertouch.org (Lanny Baron) Date: Tue Dec 2 03:03:05 2003 Subject: cannot login to FreeBSD/Samba Server from NT or from the NET or dialup.. Message-ID: Hello, As I am not subscribed to this list, if you should be able to help me, please mail me directly back. I have Samba-2.0.4b running on FreeBSD boxes. I have an NT 4 Service pack4 as the PDC. Up to a few days ago, I think just when I installed 2.0.4b from 2.0.3, I am no longer able to logon to my Samba server Freedom. It will not load my /home/lnb/Profiles, but rather constantly make a new profile. People who use some of my shares via the net can no longer get on them either. As well, anyone of my dial-ups cannot logon (they can login to the NT RAS) but they must uncheck logon to network. I have no clue what has caused this. On the phone last night to a Samba team member he also is a little stumped at this and suggested I post here. The other strange thing is. Even though when loging directly on the NT terminal and you hear the h/d chugging away on the FreeBSD/Samba server, and after about 3 minuets a message pops up that the local (yes not roaming) profile cannot be loaded, it makes a new one as stated above. However, upon click Network Neighborhood, the shares are visible on both Samba servers. I have over the last 3 days deinstalled and reinstalled both Samba and NT to see if something was corrupted. But it appears not. The permissions for the profiles for any user(using mine) are rwxr_xr_x for /home/lnb/Profiles and in the dir of Profiles is a file called netlogin.pds. It has been working flawlessly for quite a while. But all of a sudden, the more I think of it, since I installed 2.0.4b things have been getting worse. Can't print (my printer is connected to my Samba Server) from windows NT, I can print on the Samba box (cat some_file | lpr) So if you have the help I could use, please, help me out. Regards, Lanny Baron http://ca.samba.org/samba/samba.html # Samba config file created using SWAT # from freedom.cybertouch.org (216.183.4.2) # Date: 1999/06/04 20:02:31 # Global parameters [global] workgroup = CYBERTOUCH server string = Freedom Networks FreeBSD/Samba Server 1 security = DOMAIN encrypt passwords = Yes password server = WIRED username map = /usr/local/etc/username.map log file = /var/log/samba/log.%m max log size = 50 socket options = TCP_NODELAY logon script = netlogin.pds logon path = \\%N\%U\Profiles domain logons = Yes local master = No dns proxy = No wins proxy = Yes wins support = Yes [homes] comment = Home Directories read only = No browseable = No [netlogon] comment = Network Logon Service path = /usr/local/samba/lib/netlogon guest ok = Yes browseable = No [Profiles] path = \\%N\%U guest ok = Yes browseable = No [printers] comment = All Printers path = /var/spool/samba print ok = Yes browseable = No Everything else is just shares. ---------------------------------- E-Mail: Lanny Baron Date: 05-Jun-99 Time: 01:13:59 This message was sent by XFMail ---------------------------------- From greg at discreet.com Sat Jun 5 16:12:32 1999 From: greg at discreet.com (Greg Dickie) Date: Tue Dec 2 03:03:05 2003 Subject: cannot login to FreeBSD/Samba Server from NT or from the NET In-Reply-To: Message-ID: The only thing I can think of is that nt acl support is now on by default. Try turning it off. Also crank up the log level to 5 or 10 in smb.conf and look for funny stuff in the log files. I had some problems with 204b but Jeremy fixed them roght away. Greg On 05-Jun-99 Lanny Baron wrote: > Hello, > > As I am not subscribed to this list, if you should be able to help me, please > mail me directly back. > > I have Samba-2.0.4b running on FreeBSD boxes. I have an NT 4 Service pack4 > as > the PDC. Up to a few days ago, I think just when I installed 2.0.4b from > 2.0.3, > I am no longer able to logon to my Samba server Freedom. It will not load my > /home/lnb/Profiles, but rather constantly make a new profile. People who use > some of my shares via the net can no longer get on them either. As well, > anyone > of my dial-ups cannot logon (they can login to the NT RAS) but they must > uncheck logon to network. > > I have no clue what has caused this. On the phone last night to a Samba team > member he also is a little stumped at this and suggested I post here. The > other > strange thing is. Even though when loging directly on the NT terminal and > you hear the h/d chugging away on the FreeBSD/Samba server, and after > about 3 minuets a message pops up that the local (yes not roaming) profile > cannot be loaded, it makes a new one as stated above. However, upon click > Network Neighborhood, the shares are visible on both Samba servers. > > I have over the last 3 days deinstalled and reinstalled both Samba and NT to > see if something was corrupted. But it appears not. > > The permissions for the profiles for any user(using mine) are rwxr_xr_x for > /home/lnb/Profiles and in the dir of Profiles is a file called netlogin.pds. > It has been working flawlessly for quite a while. But all of a sudden, the > more > I think of it, since I installed 2.0.4b things have been getting worse. Can't > print (my printer is connected to my Samba Server) from windows NT, I can > print > on the Samba box (cat some_file | lpr) > > So if you have the help I could use, please, help me out. > > Regards, > > Lanny Baron > http://ca.samba.org/samba/samba.html > ># Samba config file created using SWAT ># from freedom.cybertouch.org (216.183.4.2) ># Date: 1999/06/04 20:02:31 > ># Global parameters > [global] > workgroup = CYBERTOUCH > server string = Freedom Networks FreeBSD/Samba Server 1 > security = DOMAIN > encrypt passwords = Yes > password server = WIRED > username map = /usr/local/etc/username.map > log file = /var/log/samba/log.%m > max log size = 50 > socket options = TCP_NODELAY > logon script = netlogin.pds > logon path = \\%N\%U\Profiles > domain logons = Yes > local master = No > dns proxy = No > wins proxy = Yes > wins support = Yes > [homes] > comment = Home Directories > read only = No > browseable = No > > [netlogon] > comment = Network Logon Service > path = /usr/local/samba/lib/netlogon > guest ok = Yes > browseable = No > > [Profiles] > path = \\%N\%U > guest ok = Yes > browseable = No > > [printers] > comment = All Printers > path = /var/spool/samba > print ok = Yes > browseable = No > > > Everything else is just shares. > ---------------------------------- > E-Mail: Lanny Baron > Date: 05-Jun-99 > Time: 01:13:59 > > This message was sent by XFMail > ---------------------------------- ---------------------------------- Greg Dickie just a guy* *from Discreet (the Logic is gone) ---------------------------------- From matthew at janus.law.usyd.edu.au Sat Jun 5 22:36:47 1999 From: matthew at janus.law.usyd.edu.au (Matthew Geier) Date: Tue Dec 2 03:03:05 2003 Subject: cannot login to FreeBSD/Samba Server from NT or from the NET In-Reply-To: from "Greg Dickie" at Jun 6, 99 02:14:09 am Message-ID: <199906052236.IAA05520@janus.law.usyd.edu.au> > > > The only thing I can think of is that nt acl support is now on by default. Try > turning it off. Also crank up the log level to 5 or 10 in smb.conf and look for > funny stuff in the log files. I had some problems with 204b but Jeremy fixed > them roght away. There is some sort of name mangling bug in 204b, im having problems with my server hosted dos batch scripts again, and the MSOffice clip art galary program is unable to load the index files off a server mounted CDROM again. 202 was fine. 204x isnt. From majid at bol.sharif.ac.ir Sun Jun 6 11:54:18 1999 From: majid at bol.sharif.ac.ir (Majid Tajamolian) Date: Tue Dec 2 03:03:05 2003 Subject: The SND/RCV LO/HI WAT options Message-ID: Dear LIST: I'm working on SAMBA performance enhancement. Can anyone guide me for a reference about the 4 WATer mark socket options and their effects on TCP/IP performance? Have anyone any experiments about using them in the SAMBA code? -- THX in advance, M. Tajamolian Jun 6 From lnb at freedom.cybertouch.org Mon Jun 7 09:25:18 1999 From: lnb at freedom.cybertouch.org (Lanny Baron) Date: Tue Dec 2 03:03:05 2003 Subject: NT4 server & Samba logons..totally confused Message-ID: Hello Samba users, note*** I am not subscribed to this list and if you answer it, please mail me back directly at lnb@cybertouch.org..thanks I am really confused. I have read quite a few of the docs with Samba-2.0.4b, with respect to having an NT server and Samba. With NT running do you have domain logons = yes ? If so, what about [profiles] and [homes]? Maybe the question should be asked, if I have Samba running what do I need NT for? I had win98 running before and everything was fine. I killed the win98 box and installed NT4. I can't transfer (either by a windows ftp client or via Network Neighborhood) my directories on the NT box so I can go back to win98. My setup (topography) is one NT box, 2 FreeBSD/Samba boxes. You might ask what the F--K am i trying to accomplish. Well, I want people to be able to dialin via RAS (setting up PPP dialup is no easy task), then to be able to logon to their /home/user on the FreeBSD/Samba box. Be able to use shares set on the FreeBSD/Samba boxes. Again I ask, other than using NT for dialup (RAS) and seeing the problems I now face, what is the purpose of NT in a Samba run domain? It's quite apparent to me that I don't understand netlogon's, and could really use some help by someone that understands what it is I am trying to do. If it turns out that what I am doing is completely nuts, please let me know. I have been at this since last Monday. Unable to upload from my NT box to my FreeBSD/Samba boxes my directories that I crucially need so that I can kill this NT box and put back Win98 and setup the smb.conf the way it was. Working perfect. It's that old story coming to haunt me. Why fix that which is not broken? Your help is GREATLY appreciated. Thank you, Lanny Baron http://ca.samba.org/samba/samba.html From majid at bol.sharif.ac.ir Mon Jun 7 14:24:54 1999 From: majid at bol.sharif.ac.ir (Majid Tajamolian) Date: Tue Dec 2 03:03:05 2003 Subject: The SND/RCV LO/HI WAT options In-Reply-To: <375BB802.B8B30F14@canada.sun.com> Message-ID: Dear David: Hi, On Mon, 7 Jun 1999, David Collier-Brown wrote: > Majid Tajamolian wrote: > > > > Dear LIST: > > I'm working on SAMBA performance enhancement. Can anyone guide me for a > > reference about the 4 WATer mark socket options and their effects on > > TCP/IP performance? > > Have anyone any experiments about using them in the SAMBA code? > > A colleague has been experimenting with them in a non-samba > context, and we've been looking at their behavior quantiatively: > Alas, I'm not doing the experiments myself... > > What would you like to know? > It seems that anything about them can be useful (i.e. their meaning, how they change the TCP behavior, what is relation between them and the other configurations such as SNDBUF, RCVBUF, TCP_MAXSEG, ...). If you don't know about them, can you help me to find some information in the internet? -- The best, M. Tajamolian Jun 7 From crh at nts.umn.edu Mon Jun 7 15:20:03 1999 From: crh at nts.umn.edu (Christopher R. Hertel) Date: Tue Dec 2 03:03:05 2003 Subject: Samba & trapdoor uid (fwd) Message-ID: <199906071520.KAA15714@unet.unet.umn.edu> This message floated across one of the OpenBSD mailing lists. I've also seen some inquiries regarding FreeBSD here on the samba-tech list. I'd like to know if the folks with FreeBSD troubles are seeing the "Trapdoor uid" message. Debug log entries would be worth-while too. I've got oBSD running so I'll give this a shot too. Chris -)----- Forwarded message: > From owner-misc@openbsd.org Fri Jun 4 23:55:06 1999 > Date: Fri, 4 Jun 1999 22:03:53 -0700 (PDT) > From: Dana Booth > To: misc_openbsd > Subject: Samba & trapdoor uid > Message-ID: > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > Sender: owner-misc@openbsd.org > > At work, I use Samba with OpenBSD. Been through versions of both, but > they're currently at obsd 2.4 and Samba 2.0.3. Runs great. > > I made Samba 2.0.4b today, and while running the configure script, a > message appeared that said, "Trapdoor uid, Samba might not run correctly". > When I tried to connect to a share from a Windows client, I got a bad > password error on the client computer, but in the Samba log, it said > something to the effect that it couldn't set the gid or uid. In the Samba > FAQ, it briefly mentioned trapdoor uid's as being a system where, when uid > is set to a user, it can't get back, or something like that. > > Okay, so I'm rambling... But does this ring a bell with anyone? I still > have it setup, I always make stuff on our real server's evil twin test box > first. I dinked with it for about half an hour, but I don't really have a > clue as to why Samba 2.0.3 works perfectly, and .4b gives me this. > > -- > > ------------------------ > Dana Booth > Tacoma, Wa., USA > ------------------------ > > -- -- I have a shoehorn, the kind with teeth. -- --- Christopher R. Hertel -)----- University of Minnesota crh@nts.umn.edu Networking and Telecommunications Services From crh at nts.umn.edu Mon Jun 7 15:24:21 1999 From: crh at nts.umn.edu (Christopher R. Hertel) Date: Tue Dec 2 03:03:05 2003 Subject: cannot login to FreeBSD/Samba Server from NT or from the NET In-Reply-To: <199906052236.IAA05520@janus.law.usyd.edu.au> from "Matthew Geier" at Jun 6, 99 08:38:21 am Message-ID: <199906071524.KAA16470@unet.unet.umn.edu> Regarding FreeBSD: I've gotten a report of a problem regarding "Trapdoor uids". Someone running FreeBSD please re-run the configure step (might help to remove config.cache) and see if you are getting a warning regarding "Trapdoor uids". If so, let us know. Regarding the name mangling bug reported below: What OS are you running? If not one of the *BSDs (or similar) then this is likely a separate problem. Chris -)----- > > The only thing I can think of is that nt acl support is now on by default. Try > > turning it off. Also crank up the log level to 5 or 10 in smb.conf and look for > > funny stuff in the log files. I had some problems with 204b but Jeremy fixed > > them roght away. > > There is some sort of name mangling bug in 204b, im having problems > with my server hosted dos batch scripts again, and the MSOffice clip > art galary program is unable to load the index files off a server mounted > CDROM again. > 202 was fine. 204x isnt. > -- -- I have a shoehorn, the kind with teeth. -- --- Christopher R. Hertel -)----- University of Minnesota crh@nts.umn.edu Networking and Telecommunications Services From tridge at samba.org Mon Jun 7 15:35:09 1999 From: tridge at samba.org (Andrew Tridgell) Date: Tue Dec 2 03:03:05 2003 Subject: Samba & trapdoor uid (fwd) In-Reply-To: <199906071520.KAA15714@unet.unet.umn.edu> (crh@nts.umn.edu) References: <199906071520.KAA15714@unet.unet.umn.edu> Message-ID: <19990607153522Z12868811-234+209@samba.anu.edu.au> > > I made Samba 2.0.4b today, and while running the configure script, a > > message appeared that said, "Trapdoor uid, Samba might not run correctly". that usually indicates one of the following: 1) that the OS has trapdoor UIDs. I think that is unlikely for OpenBSD 2) our source/tests/trapdoor.c code is broken on OpenBSD 3) somethng is screwed up on your system the last possibility is a real one, it happened to me with a RedHat 5.2 box that was partly upgraded to redHat 6.0, leaving the C library stubs in an inconsistent state so that the trapdoor test segfaulted. Have a look at config.log and see if anything unusual shows up near the trapdoor stuff. Otherwise try trapdoor.c as a standalone program and add some debug code to it. I'm tempted to remove the trapdoor detection code completely, and instead go back to our old runtime test scheme that looked for failed seteuid() calls. We have had more problems with the test than with real trapdoor platforms (which luckily are now fairly rare). From trep at cortexmachina.com Mon Jun 7 15:48:45 1999 From: trep at cortexmachina.com (Pierre-Jules Tremblay) Date: Tue Dec 2 03:03:05 2003 Subject: Samba uid->rid change in mapping in 2.1alpha Message-ID: <199906071548.LAA23276@ursula.dem.qc.ca> A non-text attachment was scrubbed... Name: not available Type: text Size: 1371 bytes Desc: not available Url : http://lists.samba.org/archive/samba-technical/attachments/19990607/9698f0d3/attachment.bat From borsenkow.msk at sni.de Mon Jun 7 16:46:31 1999 From: borsenkow.msk at sni.de (Andrej Borsenkow) Date: Tue Dec 2 03:03:05 2003 Subject: FW: 2.0.4b: unacceptable long browsing times from Windows2000 Beta3 Message-ID: <001201beb105$4bd389e0$21c9ca95@mow.siemens.ru> I have not got any reply (automated or not) from samba-bugs, so I repost it here. regards -----Original Message----- From: Andrej Borsenkow Sent: Thursday, June 03, 1999 9:21 PM To: SAMBA bugs list Subject: 2.0.4b: unacceptable long browsing times from Windows2000 Beta3 This happens both with Windows2000 Server and Advanced Server (Beta 3 Final - build 2031 I think). In Explorer, browse the network, double click on SAMBA server, than double click on any share - it takes more than five minutes! till list of files in this share appears! On SAMBA I see something like this in log: [1999/06/03 20:52:02, 1] smbd/service.c:(488) icp-340e4eib9ll (149.202.201.102) connect to service source as user nobody (ui =104, gid=102) (pid 3577) [1999/06/03 20:52:17, 1] smbd/service.c:(512) icp-340e4eib9ll (149.202.201.102) closed connection to service source [1999/06/03 20:54:52, 0] lib/util_sock.c:(384) read_data: read failure for 4. Error = Connection reset by peer [1999/06/03 20:57:08, 0] lib/util_sock.c:(384) read_data: read failure for 4. Error = Connection reset by peer [1999/06/03 20:59:25, 0] lib/util_sock.c:(384) read_data: read failure for 4. Error = Connection reset by peer [1999/06/03 20:59:25, 1] smbd/service.c:(488) icp-340e4eib9ll (149.202.201.102) connect to service source as user nobody (ui d=104, gid=102) (pid 3662) I have full Netmon capture with text printout (bear in mind, that it is NT5 netmon, that is not compatible with NT4). I'm happy to send it to anybody interested and to provide any additional info. Note, that if share is mapped first and then accessed through mapped drive, it works normal. Browsing NT4 server also works as expected. regards /andrej From crh at nts.umn.edu Mon Jun 7 17:13:03 1999 From: crh at nts.umn.edu (Christopher R. Hertel) Date: Tue Dec 2 03:03:05 2003 Subject: Samba & trapdoor uid (fwd) In-Reply-To: <19990607153522Z12868811-234+209@samba.anu.edu.au> from "Andrew Tridgell" at Jun 8, 99 01:35:09 am Message-ID: <199906071713.MAA01843@unet.unet.umn.edu> Curious. I compiled 2.0.4b on OpenBSD 2.5 as myself and as root. If I compile as myself, I *don't* get the "Trapdoor uid, Samba might not run correctly" message. If I compile as root I do. ...some tests disabled? Chris -)----- > > I made Samba 2.0.4b today, and while running the configure script, a > > message appeared that said, "Trapdoor uid, Samba might not run correctly". > > I'm tempted to remove the trapdoor detection code completely, and > instead go back to our old runtime test scheme that looked for failed > seteuid() calls. We have had more problems with the test than with > real trapdoor platforms (which luckily are now fairly rare). > -- -- I have a shoehorn, the kind with teeth. -- --- Christopher R. Hertel -)----- University of Minnesota crh@nts.umn.edu Networking and Telecommunications Services From dana at oz.net Mon Jun 7 17:17:34 1999 From: dana at oz.net (Dana Booth) Date: Tue Dec 2 03:03:05 2003 Subject: Samba & trapdoor uid (fwd) References: <199906071713.MAA01843@unet.unet.umn.edu> Message-ID: <375BFEAE.5CF338E@oz.net> "Christopher R. Hertel" wrote: > > Curious. I compiled 2.0.4b on OpenBSD 2.5 as myself and as root. If I > compile as myself, I *don't* get the "Trapdoor uid, Samba might not run > correctly" message. If I compile as root I do. I noticed that in /source/tests/trapdoor.c, running as non-root exits stderr 0 right off the bat, before any tests. -- ------------------------ Dana Booth Taocma, Wa., USA ------------------------ From crh at nts.umn.edu Mon Jun 7 17:29:32 1999 From: crh at nts.umn.edu (Christopher R. Hertel) Date: Tue Dec 2 03:03:05 2003 Subject: Samba & trapdoor uid (fwd) In-Reply-To: <375BFEAE.5CF338E@oz.net> from "Dana Booth" at Jun 7, 99 10:17:34 am Message-ID: <199906071729.MAA04023@unet.unet.umn.edu> > "Christopher R. Hertel" wrote: > > > > Curious. I compiled 2.0.4b on OpenBSD 2.5 as myself and as root. If I > > compile as myself, I *don't* get the "Trapdoor uid, Samba might not run > > correctly" message. If I compile as root I do. > > I noticed that in /source/tests/trapdoor.c, running as non-root exits > stderr 0 right off the bat, before any tests. Quick test, then, would be to disable the test, possibly by compiling as non-root. Curious, though... I didn't see the "ERROR: This test must be run as root - assuming non-trapdoor system" message. I'd guess that the test isn't run at all. I'll have to take a look. Any comments, Alexandre? Chris -)----- -- -- I have a shoehorn, the kind with teeth. -- --- Christopher R. Hertel -)----- University of Minnesota crh@nts.umn.edu Networking and Telecommunications Services From dana at oz.net Mon Jun 7 17:59:34 1999 From: dana at oz.net (Dana Booth) Date: Tue Dec 2 03:03:05 2003 Subject: Samba & trapdoor uid (fwd) References: <199906071729.MAA04023@unet.unet.umn.edu> Message-ID: <375C0886.F905AA9@oz.net> "Christopher R. Hertel" wrote: > Quick test, then, would be to disable the test, possibly by compiling as > non-root. > > Curious, though... I didn't see the "ERROR: This test must be run as root I just removed any trapdoor checking in the configure script, and set the: samba_cv_HAVE_TRAPDOOR_UID=no within the script, and Samba runs okay now. The trapdoor.c file, when run alone by root, gives stderr 0, yet for some reason, the configure script thinks otherwise. I didn't get out the microscope, and I don't know too much about such things, anyway. -- ------------------------ Dana Booth Taocma, Wa., USA ------------------------ From crh at nts.umn.edu Mon Jun 7 20:17:28 1999 From: crh at nts.umn.edu (Christopher R. Hertel) Date: Tue Dec 2 03:03:05 2003 Subject: Warnings under OpenBSD Message-ID: <199906072017.PAA26341@unet.unet.umn.edu> I've been fiddling with Samba on OpenBSD in an effort to help with the trapdoor.c problem on that platform. If I run ./configure under my own account, the trapdoor.c test in never run. As Dana pointed out, Samba 2.0.4b then runs correctly under OpenBSD. However, the following compile-time warnings are generated (these are sorted and uniq'd): lib/util_sec.o: warning: this program uses setregid(), which is deprecated. lib/util_sec.o: warning: this program uses setreuid(), which is deprecated. smbd/filename.o: warning: mktemp() possibly used unsafely; consider using mkstemp() smbd/message.o: warning: mktemp() possibly used unsafely; consider using mkstemp() smbd/reply.o: warning: mktemp() possibly used unsafely; consider using mkstemp() These may be specific to OpenBSD. Comments? Chris -)----- -- -- I have a shoehorn, the kind with teeth. -- --- Christopher R. Hertel -)----- University of Minnesota crh@nts.umn.edu Networking and Telecommunications Services From mh at bacher.at Mon Jun 7 23:28:25 1999 From: mh at bacher.at (Martin Hofbauer Bacher Systems EDV) Date: Tue Dec 2 03:03:05 2003 Subject: Roadmap vor 2.x release Message-ID: Many user are waiting for the PDC stuff to be released ! IS there a ( mini) roadmap for the upcomming samba releases (features ) ? What is the current state of the release time of 2.1 ? Especially LDAP Support ! I ( and I think many others, too ) need it for planing the next SMB Server implementations, migrations, colsolitations Thank you ------------------------------------------------------------------- Martin Hofbauer IT-Consulting phone : +43 (1) 60 126-34 Bacher Systems EDV GmbH fax : +43 (1) 60 126-4 Wienerbergstr. 11B e-mail: mh@bacher.at A-1101 Vienna, Austria -- From M.Strasser at gpo.com Tue Jun 8 01:32:06 1999 From: M.Strasser at gpo.com (Michael Strasser) Date: Tue Dec 2 03:03:05 2003 Subject: Samba & trapdoor uid (fwd) Message-ID: <199906080132.LAA13390@uq.net.au> I have the same problem with Samba 2.0.4b on OpenBSD 2.5 (trapdoor message during configure; compile OK; then password errors using smbclient after *carefully* checking options in smb.conf). >> > > I made Samba 2.0.4b today, and while running the configure script, a >> > > message appeared that said, "Trapdoor uid, Samba might not run correctly". >> >> that usually indicates one of the following: >> >> 1) that the OS has trapdoor UIDs. I think that is unlikely for OpenBSD >> 2) our source/tests/trapdoor.c code is broken on OpenBSD >> 3) somethng is screwed up on your system In my case I would not have jumped at number 3 because mine was a brand new install of OpenBSD (i386) from CD onto a new partition. I don't think I've added anything to the system that might cause a problem. I have a custom kernel but its only change is to use the RTC on the PC set to local time (the system is a test bed and spends most of its life running Windows). >> Have a look at config.log and see if anything unusual shows up near >> the trapdoor stuff. Otherwise try trapdoor.c as a standalone program >> and add some debug code to it. I will check this out during the next couple of days. That error message comes up during the configuration phase. Does it affect how Samba compiles and runs, if the warning itself is spurious? Michael Strasser StrassCom Pty Ltd A.C.N. 081 228 471 Consulting and Training in Information Technology 50 Holland Street, Greenslopes Qld 4120, Australia Phone: +61 4 1428 4256 Fax: +61 7 3397 7167 From tridge at samba.org Tue Jun 8 09:58:23 1999 From: tridge at samba.org (Andrew Tridgell) Date: Tue Dec 2 03:03:05 2003 Subject: lots of clients with vmware Message-ID: <19990608095836Z12875116-2675+460@samba.anu.edu.au> I've now setup a bunch of different clients under vmware on a RH6 host for Samba testing. I have working: - Win98 - NT4.0SP4 srv - NT4.0SP4 wks - WfWg3.11 - DOS6.22 + LANMAN enhanced - NT3.51 server This is good, as it's been a long time since I've been able to test some of these clients with Samba. The only Samba problem I've hit so far is that NT3.51 fails to view the new security/permissions stuff in Samba 2.04b. It gives a "bad parameter" error (although viewing the ownership on files is OK). That confirms a bug report that Jeremy had received from a WinDD user. I'll see if I can fix it later tonight. Cheers, Tridge From Peter.Galbavy at knowledge.com Tue Jun 8 10:10:53 1999 From: Peter.Galbavy at knowledge.com (Peter Galbavy) Date: Tue Dec 2 03:03:05 2003 Subject: Warnings under OpenBSD In-Reply-To: <199906072017.PAA26341@unet.unet.umn.edu>; from Christopher R. Hertel on Tue, Jun 08, 1999 at 06:18:24AM +1000 References: <199906072017.PAA26341@unet.unet.umn.edu> Message-ID: <19990608111052.C15917@office.knowledge.com> The OpenBSD ld has these message built in as warnings about "unsafe" well known functions. There is various literature on the safe use (or really the unsafe use) of at least these, plus strcpy/strcat et al. I still don't understand the setre*() race condition, since the OpenBSD "gurus" are too arogant to explain or document these. The attitude is one of "if you don't understand it, don't ask the question." The mktemp() replacement mkstemp() removes the race condition my returning you a file handle rather than a file name to then open(). On Tue, Jun 08, 1999 at 06:18:24AM +1000, Christopher R. Hertel wrote: > I've been fiddling with Samba on OpenBSD in an effort to help with the > trapdoor.c problem on that platform. If I run ./configure under my own > account, the trapdoor.c test in never run. As Dana pointed out, Samba > 2.0.4b then runs correctly under OpenBSD. However, the following > compile-time warnings are generated (these are sorted and uniq'd): > > lib/util_sec.o: warning: this program uses setregid(), which is deprecated. > lib/util_sec.o: warning: this program uses setreuid(), which is deprecated. > smbd/filename.o: warning: mktemp() possibly used unsafely; consider using mkstemp() > smbd/message.o: warning: mktemp() possibly used unsafely; consider using mkstemp() > smbd/reply.o: warning: mktemp() possibly used unsafely; consider using mkstemp() > > These may be specific to OpenBSD. > > Comments? > > Chris -)----- > > -- > -- I have a shoehorn, the kind with teeth. -- > --- > Christopher R. Hertel -)----- University of Minnesota > crh@nts.umn.edu Networking and Telecommunications Services -- Peter Galbavy Knowledge Matters Ltd http://www.knowledge.com/ From tridge at samba.org Tue Jun 8 12:49:39 1999 From: tridge at samba.org (Andrew Tridgell) Date: Tue Dec 2 03:03:05 2003 Subject: Warnings under OpenBSD In-Reply-To: <19990608111052.C15917@office.knowledge.com> (message from Peter Galbavy on Tue, 8 Jun 1999 20:12:08 +1000) References: <199906072017.PAA26341@unet.unet.umn.edu> <19990608111052.C15917@office.knowledge.com> Message-ID: <19990608124946Z12875885-2877+467@samba.anu.edu.au> > The attitude is one of "if you don't understand it, don't ask the > question." pity > The mktemp() replacement mkstemp() removes the race condition my > returning you a file handle rather than a file name to then open(). which is no good for the way we use mktemp() in Samba. We *need* the filename as it gets passed back to the client so we need a real file, not a handle pointing at an unlinked file. We use mktemp() safely by including the O_EXCL bit in the open. unfortunately these sort of "dumb programmer detection" systems don't detect when someone is using a oft-abused function correctly, so they spit out warnings, which means our mailboxes fill up with people telling us that we have a security hole. it's tempting to write out own mktemp() just to avoid these damn emails, it just seems so stupid as what we need is exactly what mktemp() gives, and I hate coding around idiotic warnings. > > lib/util_sec.o: warning: this program uses setregid(), which is deprecated. does the man page say what the preferred alternative to setregid() is for OpenBSD? the irony is that we started using setregid() when available because other OSes deprecated the use of setegid() and instead encouraged setregid(). From crh at nts.umn.edu Tue Jun 8 16:37:16 1999 From: crh at nts.umn.edu (Christopher R. Hertel) Date: Tue Dec 2 03:03:05 2003 Subject: Warnings under OpenBSD In-Reply-To: <19990608124946Z12875885-2877+467@samba.anu.edu.au> from "Andrew Tridgell" at Jun 8, 99 10:50:35 pm Message-ID: <199906081637.LAA22779@unet.unet.umn.edu> > > > The attitude is one of "if you don't understand it, don't ask the > > question." > > pity Yes. From what I understand, OpenBSD was born out of a rift within the NetBSD development group. On the plus side, the OpenBSD crowd are very sticky about security and the product is very nice. On the minus side, there is little effort at etiquette. I have, so far, found it worth-while to put up with this. Also, I'd note that they much less support than the Linux community, and so less time for explanations or pleasantries. > > The mktemp() replacement mkstemp() removes the race condition my > > returning you a file handle rather than a file name to then open(). > > which is no good for the way we use mktemp() in Samba. We *need* the > filename as it gets passed back to the client so we need a real file, > not a handle pointing at an unlinked file. We use mktemp() safely by > including the O_EXCL bit in the open. Cool. > unfortunately these sort of "dumb programmer detection" systems don't > detect when someone is using a oft-abused function correctly, so they > spit out warnings, which means our mailboxes fill up with people > telling us that we have a security hole. Now, now. I just asked for comments. ;) > it's tempting to write out own mktemp() just to avoid these damn > emails, it just seems so stupid as what we need is exactly what > mktemp() gives, and I hate coding around idiotic warnings. Sorry, Andrew. Didn't know it was a hot button. > > > lib/util_sec.o: warning: this program uses setregid(), which is deprecated. > > does the man page say what the preferred alternative to setregid() is > for OpenBSD? The OpenBSD man page for setregid() says this: "The setregid() function was intended to allow swapping the real and effective group IDs in set-group-ID programs to temporarily relinquish the set-group-ID value. This function did not work correctly, and its purpose is now better served by the use of the setegid() function (see setuid(2))." Urq. Full manual page info available at: http://www.openbsd.org/cgi-bin/man.cgi > the irony is that we started using setregid() when available because > other OSes deprecated the use of setegid() and instead encouraged > setregid(). ...and OpenBSD does the opposite. I'd be interested to know what "doesn't work correctly" regarding setreguid(). I'll ask (and then immediately duck for cover). Chris -)----- -- -- I have a shoehorn, the kind with teeth. -- --- Christopher R. Hertel -)----- University of Minnesota crh@nts.umn.edu Networking and Telecommunications Services From crh at nts.umn.edu Tue Jun 8 17:11:31 1999 From: crh at nts.umn.edu (Christopher R. Hertel) Date: Tue Dec 2 03:03:05 2003 Subject: Samba & trapdoor uid (fwd) In-Reply-To: <199906080132.LAA13390@uq.net.au> from "Michael Strasser" at Jun 8, 99 11:34:34 am Message-ID: <199906081711.MAA27181@unet.unet.umn.edu> > I have the same problem with Samba 2.0.4b on OpenBSD 2.5 (trapdoor message > during configure; compile OK; then password errors using smbclient after > *carefully* checking options in smb.conf). If you compile as non-root you won't see the error message and won't have the problem. > >> 1) that the OS has trapdoor UIDs. I think that is unlikely for OpenBSD > >> 2) our source/tests/trapdoor.c code is broken on OpenBSD > >> 3) somethng is screwed up on your system It appears to be #2, based on the work we've done so far. > I will check this out during the next couple of days. That error message > comes up during the configuration phase. Does it affect how Samba compiles > and runs, if the warning itself is spurious? Our experience so far is that if you get that error during the configuration on OpenBSD you are likely to have problems during run-time. Quick fix is to disable the trapdoor.c test. This is very easily done by compiling as non-root. Note, though, that this work-around hasn't been fully tested and I have no idea if other tests will be lost. It's simply quick and appears to work. Chris -)----- -- -- I have a shoehorn, the kind with teeth. -- --- Christopher R. Hertel -)----- University of Minnesota crh@nts.umn.edu Networking and Telecommunications Services From crh at nts.umn.edu Tue Jun 8 17:22:55 1999 From: crh at nts.umn.edu (Christopher R. Hertel) Date: Tue Dec 2 03:03:05 2003 Subject: lots of clients with vmware In-Reply-To: <19990608095836Z12875116-2675+460@samba.anu.edu.au> from "Andrew Tridgell" at Jun 8, 99 07:59:32 pm Message-ID: <199906081722.MAA28691@unet.unet.umn.edu> > I've now setup a bunch of different clients under vmware on a RH6 host > for Samba testing. I have working: > > - Win98 > - NT4.0SP4 srv > - NT4.0SP4 wks > - WfWg3.11 > - DOS6.22 + LANMAN enhanced > - NT3.51 server This is exceedingly cool. I gotta get a bigger disk (and some time to install vmware)! Chris -)----- -- -- I have a shoehorn, the kind with teeth. -- --- Christopher R. Hertel -)----- University of Minnesota crh@nts.umn.edu Networking and Telecommunications Services From tridge at samba.org Wed Jun 9 00:14:56 1999 From: tridge at samba.org (Andrew Tridgell) Date: Tue Dec 2 03:03:05 2003 Subject: Warnings under OpenBSD In-Reply-To: <199906081637.LAA22779@unet.unet.umn.edu> (crh@nts.umn.edu) References: <199906081637.LAA22779@unet.unet.umn.edu> Message-ID: <19990609001500Z12879606-5156+7@samba.anu.edu.au> > > unfortunately these sort of "dumb programmer detection" systems don't > > detect when someone is using a oft-abused function correctly, so they > > spit out warnings, which means our mailboxes fill up with people > > telling us that we have a security hole. > > Now, now. I just asked for comments. ;) oh, I didn't mean your email, I don't mind people like you asking about stuff like this, what I was referring to was all the emails telling me "samba has a security hole because it uses mktemp()". > ...and OpenBSD does the opposite. I'd be interested to know what > "doesn't work correctly" regarding setreguid(). I'll ask (and then > immediately duck for cover). ok. the main thing to find out is if it is a problem on other platforms too, in which case we might switch to using setegid() by default again. Cheers, Tridge From tridge at samba.org Wed Jun 9 11:59:27 1999 From: tridge at samba.org (Andrew Tridgell) Date: Tue Dec 2 03:03:05 2003 Subject: SMBcopy is failing In-Reply-To: <199906090751.NAA12965@brahma.roc.com> (message from Krishna Kishore on Wed, 9 Jun 1999 17:49:44 +1000) References: <199906090751.NAA12965@brahma.roc.com> Message-ID: <19990609115929Z12609619-11226+213@samba.anu.edu.au> > Can any one please tell me why SMBcopy is failing  or 
> what could be the fault in  my implemention.
I think you'll find that SMBcopy is broken in many SMB servers. It isn't used by any MS client as far as I know, so it only gets tested by OS/2 clients. If you work with SMB for a while then you'll find that anything that isn't used by MS clients probably doesn't work. if you really want to use SMBcopy then test it against a Samba server. At least then you can get some decent diagnostics as to why it's failing. From abakun at reac.com Wed Jun 9 16:48:24 1999 From: abakun at reac.com (Andy Bakun) Date: Tue Dec 2 03:03:05 2003 Subject: out of file structures Message-ID: <375E9AD8.3A010033@reac.com> I'm currently in the process of cleaning up after an ex-employee, and part of this is to copy a lot of cdroms to our fileserver. In the middle of copying some of the larger ones, I get a "network error" from NT, and this in samba's log: [1999/06/09 11:38:19, 0] smbd/files.c:file_new(85) ERROR! Out of file structures After this, samba just stops responding, and I have to kill the process to recover my session and continue to use the server. The most recent copy it failed on was copying 601 files spread over 135 directories, totaling about 655650k. Any ideas, suggestions? Andy. From jallison at cthulhu.engr.sgi.com Wed Jun 9 16:54:18 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:05 2003 Subject: out of file structures References: <375E9AD8.3A010033@reac.com> Message-ID: <375E9C3A.C00F1D9C@engr.sgi.com> Andy Bakun wrote: > > I'm currently in the process of cleaning up after an ex-employee, and part > of this is to copy a lot of cdroms to our fileserver. In the middle of > copying some of the larger ones, I get a "network error" from NT, and this > in samba's log: > > [1999/06/09 11:38:19, 0] smbd/files.c:file_new(85) > ERROR! Out of file structures > > After this, samba just stops responding, and I have to kill the process to > recover my session and continue to use the server. The most recent copy it > failed on was copying 601 files spread over 135 directories, totaling about > 655650k. Any ideas, suggestions? Yes. Can you reproduce this at will ? Andrew and I have been tracking this one and are trying to determine what the problem is. If you can reproduce it then I'll send a patch that adds file structure resource tracing and we can nail the problem. Thanks, Jeremy. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From abakun at reac.com Wed Jun 9 17:00:30 1999 From: abakun at reac.com (Andy Bakun) Date: Tue Dec 2 03:03:05 2003 Subject: out of file structures References: <375E9AD8.3A010033@reac.com> <375E9C3A.C00F1D9C@engr.sgi.com> Message-ID: <375E9DAE.3D4CB8E@reac.com> I believe I can, just by trying to copy the same cd again. I don't know if it fails in the same place or not, but I guess we'll find out. I'll let you know. Jeremy Allison wrote: > Yes. Can you reproduce this at will ? Andrew and I have > been tracking this one and are trying to determine what > the problem is. > > If you can reproduce it then I'll send a patch that > adds file structure resource tracing and we can nail > the problem. From cfandre at cfsmo.honeywell.com Wed Jun 9 18:23:52 1999 From: cfandre at cfsmo.honeywell.com (Clay Fandre) Date: Tue Dec 2 03:03:05 2003 Subject: Connecting to shares across different domains Message-ID: <375EB138.7DB194C8@cfsmo.honeywell.com> Is it possible to connect to shares across different domains? We have 2 domains, X (local) and Y (remote) and we authenticate via our NT PDC on domain X. Can users on the remote domain Y connect to shares on domain X? Does there need to be a trust relationship? And if so, how? Thanks. Clay -- Clay Fandre Honeywell, Inc. / CAS-SPO cfandre@cfsmo.honeywell.com (612)957-3678 From Peter.Galbavy at knowledge.com Wed Jun 9 18:48:30 1999 From: Peter.Galbavy at knowledge.com (Peter Galbavy) Date: Tue Dec 2 03:03:05 2003 Subject: out of file structures In-Reply-To: <375E9C3A.C00F1D9C@engr.sgi.com>; from Jeremy Allison on Thu, Jun 10, 1999 at 02:55:54AM +1000 References: <375E9AD8.3A010033@reac.com> <375E9C3A.C00F1D9C@engr.sgi.com> Message-ID: <19990609194830.B28222@office.knowledge.com> On Thu, Jun 10, 1999 at 02:55:54AM +1000, Jeremy Allison wrote: > Yes. Can you reproduce this at will ? Andrew and I have > been tracking this one and are trying to determine what > the problem is. Just as point to note, I have had the same symptoms here with a Win98 box, but did not have the thought to check the log files - which are long gone. I can try to reproduce it and read some logs if it useful. The basics are as described, and *only* happen when trying to dump the contents of a CDROM to a networked drive. Windows 98 though. Regards, -- Peter Galbavy Knowledge Matters Ltd http://www.knowledge.com/ From alan at lxorguk.ukuu.org.uk Wed Jun 9 19:01:21 1999 From: alan at lxorguk.ukuu.org.uk (Alan Cox) Date: Tue Dec 2 03:03:05 2003 Subject: Do not use stock RedHat 6.0 kernels with SMBFS! In-Reply-To: <199906091531.LAA23286@alcove.wittsend.com> from "Michael H. Warfield" at Jun 9, 99 11:31:45 am Message-ID: A non-text attachment was scrubbed... Name: not available Type: text Size: 570 bytes Desc: not available Url : http://lists.samba.org/archive/samba-technical/attachments/19990609/78775f4b/attachment.bat From Matthew.Wilcox at genedata.com Wed Jun 9 19:21:19 1999 From: Matthew.Wilcox at genedata.com (Matthew Wilcox) Date: Tue Dec 2 03:03:05 2003 Subject: Do not use stock RedHat 6.0 kernels with SMBFS! In-Reply-To: <199906091531.LAA23286@alcove.wittsend.com>; from Michael H. Warfield on Wed, Jun 09, 1999 at 11:31:45AM -0400 References: <199906091531.LAA23286@alcove.wittsend.com> Message-ID: <19990609212119.Z1415@mencheca.ch.genedata.com> On Wed, Jun 09, 1999 at 11:31:45AM -0400, Michael H. Warfield wrote: > The Windows 95 Bug Workaround forces "ON" some protocol > hacks to work around bugs in Windows 95. The code for this hack > is in the kernel even if this option is disabled. If the option > is disabled, the bug workaround is "OFF" by default but can be > enabled with a mount time option. If the Windows 95 Bug Workaround > is enabled when the kernel is compiled, this code is forced "ON" > with no way to disable it. This code is strictly for Windows 95 > shares and causes havoc with Windows NT, Windows 2000, and Windows 98 > shares. Then surely this option should be removed from the makefiles immediately. Why does this option exist at all? (Apart from hysterical raisons, which don't count.) -- Matthew Wilcox "Windows and MacOS are products, contrived by engineers in the service of specific companies. Unix, by contrast, is not so much a product as it is a painstakingly compiled oral history of the hacker subculture." - N Stephenson From mhw at wittsend.com Wed Jun 9 19:34:41 1999 From: mhw at wittsend.com (Michael H. Warfield) Date: Tue Dec 2 03:03:05 2003 Subject: Do not use stock RedHat 6.0 kernels with SMBFS! In-Reply-To: from Alan Cox at "Jun 9, 1999 08:01:21 pm" Message-ID: <199906091934.PAA27941@alcove.wittsend.com> Alan Cox enscribed thusly: > > This problem may also have been present with the SMBFS module > > and smbmount program from the 2.0 kernels. Since I do not maintain > > that version of smbmount, I'm unaware if the problem existed in those > > earlier versions or not. > As far as I am aware Red Hat, and most of the other vendors ship with the > win95 work around enabled as that (at least was) the normal platform, and > crashing win95 boxes would give Linux a bad name, even if it wasnt Linux > fault. Hmmm... Crashing Windows 95 SERVERS sounds like a feature to me. I'm really not sure what's worse. The reputation if we crash Windows 95 when it's used as a server (YUCK) or the reputation we get when the file systems appear to be corrupted with REAL SERVERS (not counting Windows 98 in the real servers category, but you get what I mean). Maybe we should have two options. One being the Windows 95 slow down the protocol option to prevent us from nuking Windows 95 boxes because they can't handle the timing. The other being a Windows 95 inane byte bass ackards option to fix timestamps. Actually, the correct fix is to get the $#@$#@ autodetect in, I know. > The real big problem is that the WIN95 workaround isnt a mount option. Or > better yet autodetected. Wwweeelll... Actually it is, but it's a gross ugly hack and I have no clue who did it. If you look in the smbfs code you find that it checks one of the bits in the file mode (the sticky bit I think) and flips on the WIN95 bug workaround based on that. It's in this little stretch of code in fs/smbfs/inode.c: ======================================================== /* ** temp ** pass config flags in file mode */ mnt->version = (mnt->file_mode >> 9); #ifdef CONFIG_SMB_WIN95 mnt->version |= SMB_FIX_WIN95; #endif ======================================================== So SMB_FIX_WIN95 is defined as 1 so that means that bit 9 of the file mode becomes that SMB_FIX_WIN95 flag in the version element of that mount structure. So you turn it on with a -f 1xxx in the file mode. The CONFIG_SMB_WIN95 merely forces that bit on for each and EVERY smbfs mount. It would have been one hell of a lot better if that had been an XOR so we at least had the ability to disable it using the gross ugly hack. The rest of the code merely checks the SMB_FIX_WIN95 bit in the version field for switching those options, so it all follows from the file permissions and then the compile option. Now don't hit me! I didn't do it! I'm not responsible for that module! :-) I was going to add a -9 option to smbmount to "or" that flag in. I figure I could have gotten away with adding the option and telling everyone about the option without telling them that it was just and interface to a gross ugly hack and get away with it... Oh well... With the compile option enabled, you have no way to disable it. With the compile option enabled, you CAN enable or disable it on a mount by mount basis, it just isn't pretty. Tridge and Luke and I did discuss something about an autodetect. I just haven't gotten around to figuring out if it belongs in the smbmount program (likely) and passed down to smbfs in the gross ugly hack field or if it belongs in smbfs to figure out and we can do away with the gross ugly hack. It probably should be detected in smbmount and passed through in it's own structure element, but that means changing that interface AGAIN! Tridge and Luke and John and the rest of the Samba team don't want to go near that module. That's why I ended up on the team dealing with smbmount. And maintainership of smbfs did not go along with maintainership of smbmount. BTW... The MAINTAINERS file is also wrong in the kernel sources. Volker is no longer maintaining smbfs (and hasn't for a long time) and the Samba mailing list was never the mailing list for smbfs (I just found out that it was listed there). > Alan Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From mtrausch at wcnet.org Wed Jun 9 19:39:30 1999 From: mtrausch at wcnet.org (Michael B. Trausch) Date: Tue Dec 2 03:03:05 2003 Subject: Do not use stock RedHat 6.0 kernels with SMBFS! In-Reply-To: <199906091531.LAA23286@alcove.wittsend.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Um, quite frankly, why would anyone use the stock kernel anyway? The point of the stock kernel is to get the system running well enough to get a custom compiled kernel, IMHO. Besides, the stock kernel for RH 6.0 isn't all that good anyway - I get TONS better performance on my own compiled kernels... and not NEARLY as much space in modules. On Wed, 9 Jun 1999, Michael H. Warfield wrote: > Ok... I reported this problem to RedHat several days > ago, so they have had at least a small chance to look it over and > be ready for this announcement. I'm continuing to hear complaints > about corrupted timestamps on smbfs mounts so this word needs to > get out. > - ------------------------------------------------------------------------ Michael B. Trausch President of Linux Operations, ADK Computers http://adk.hypermart.net/ - ------------------------------------------------------------------------ PGP Public Key is available at a Key Server near you, or at: http://wcnet.org/~mtrausch/pubkey.txt - ------------------------------------------------------------------------ ADK Computers, Walbridge Office E-Mail: mtrausch@wcnet.org - ------------------------------------------------------------------------ To fall in love is to create a religion that has a fallible god. - JLB Life is a comedy for those who think and a tragedy for those who feel. Love is friendship set on fire. - French Proverb Customer: I'm running Windows '98 Tech: Yes. Customer: My computer isn't working now. Tech: Yes, you said that. -----BEGIN PGP SIGNATURE----- Version: GnuPG v0.9.7 (GNU/Linux) Comment: Made with PGP4Pine iD8DBQE3XsL0BtYAauOptokRAs9BAJ9/3fy9MbmiBAJFeA58Erp/ZBOJbACfdPzY LJJyegyWgtLv2+SoNisvZ6I= =K5Vx -----END PGP SIGNATURE----- From dwguest at win.tue.nl Wed Jun 9 19:56:35 1999 From: dwguest at win.tue.nl (Guest section DW) Date: Tue Dec 2 03:03:05 2003 Subject: Do not use stock RedHat 6.0 kernels with SMBFS! Message-ID: <199906091956.VAA04748@wsdw01.win.tue.nl> alan: The real big problem is that the WIN95 workaround isnt a mount option. But it is. The bug is that the kernel has a CONFIG_SMB_WIN95 that overrules the mount option. Just delete all mention of CONFIG_SMB_WIN95 from the kernel source (that is, from fs/Config.in, fs/smbfs/inode.c and Documentation/Configure.help, Documentation/filesystems/smbfs.txt) and all will be well. Andries From vorlon at netexpress.net Wed Jun 9 20:11:03 1999 From: vorlon at netexpress.net (Stephen Langasek) Date: Tue Dec 2 03:03:05 2003 Subject: Do not use stock RedHat 6.0 kernels with SMBFS! In-Reply-To: Message-ID: On Thu, 10 Jun 1999, Michael B. Trausch wrote: > Um, quite frankly, why would anyone use the stock kernel anyway? The > point of the stock kernel is to get the system running well enough to get > a custom compiled kernel, IMHO. > > Besides, the stock kernel for RH 6.0 isn't all that good anyway - I get > TONS better performance on my own compiled kernels... and not NEARLY as > much space in modules. This is all the more important an issue because it affects those novice users who don't know how to recompile their kernel to fix the problem, or those large installations who don't have time to do so on all their machines. The fact that the default kernel needs to be general-purpose and non-optimized is no excuse for it to be broken... -Steve Langasek postmodern programmer From mhw at wittsend.com Wed Jun 9 20:35:38 1999 From: mhw at wittsend.com (Michael H. Warfield) Date: Tue Dec 2 03:03:05 2003 Subject: Do not use stock RedHat 6.0 kernels with SMBFS! In-Reply-To: from Alan Cox at "Jun 9, 1999 08:01:21 pm" Message-ID: <199906092035.QAA29079@alcove.wittsend.com> Alan, Alan Cox enscribed thusly: > > This problem may also have been present with the SMBFS module > > and smbmount program from the 2.0 kernels. Since I do not maintain > > that version of smbmount, I'm unaware if the problem existed in those > > earlier versions or not. > As far as I am aware Red Hat, and most of the other vendors ship with the > win95 work around enabled as that (at least was) the normal platform, and > crashing win95 boxes would give Linux a bad name, even if it wasnt Linux > fault. > The real big problem is that the WIN95 workaround isnt a mount option. Or > better yet autodetected. One other point about this... While there is a mount option (ugly), the mount option is totally inoperative when the compile option is enabled (yes, I had a slight typo in my previous message where I said enabled twice). Even IF I put the code into smbmount to autodetect the Windows 95 connections (which I want to do), the user space program can not override that compile option if it's enabled. If the compile option is disabled, I can set or clear that "feature" on a mount-by-mount, connection-by-connection, basis. As long as that option is enabled in the build, I'm screwed. I can't do anything from user space to correct the problem. > Alan Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From abakun at reac.com Wed Jun 9 21:18:50 1999 From: abakun at reac.com (Andy Bakun) Date: Tue Dec 2 03:03:05 2003 Subject: out of file structures References: <375E9AD8.3A010033@reac.com> <375E9C3A.C00F1D9C@engr.sgi.com> Message-ID: <375EDA3A.56556148@reac.com> I have reproduced it twice. Both times, it stopped in apparently the same place, after copying a total of 1136 files and 246 directories. I had to copy that cd twice in succession -- it would fail on the second time. The cd itself contains 601 files and 136 directories. No other SMB relation activities were going on on the client machine at the time. Jeremy Allison wrote: > Yes. Can you reproduce this at will ? Andrew and I have > been tracking this one and are trying to determine what > the problem is. > > If you can reproduce it then I'll send a patch that > adds file structure resource tracing and we can nail > the problem. From alan at lxorguk.ukuu.org.uk Wed Jun 9 21:10:44 1999 From: alan at lxorguk.ukuu.org.uk (Alan Cox) Date: Tue Dec 2 03:03:05 2003 Subject: Do not use stock RedHat 6.0 kernels with SMBFS! In-Reply-To: <199906091956.VAA04748@wsdw01.win.tue.nl> from "Guest section DW" at Jun 9, 99 09:56:35 pm Message-ID: A non-text attachment was scrubbed... Name: not available Type: text Size: 605 bytes Desc: not available Url : http://lists.samba.org/archive/samba-technical/attachments/19990609/ff04b401/attachment.bat From crh at nts.umn.edu Wed Jun 9 21:29:14 1999 From: crh at nts.umn.edu (Christopher R. Hertel) Date: Tue Dec 2 03:03:05 2003 Subject: out of file structures Message-ID: <199906092129.QAA14914@unet.unet.umn.edu> > I have reproduced it twice. Both times, it stopped in apparently the > same place, after copying a total of 1136 files and 246 directories. I > had to copy that cd twice in succession -- it would fail on the second > time. The cd itself contains 601 files and 136 directories. > No other SMB relation activities were going on on the client machine at > the time. Wildly off the cuff here, but it *sounds* as though we're incrementing some counter somewhere (samba file descriptor number or some such) and not wrapping properly when we reach an upper bound. Of course, that's either blindingly obvious or miles off base. Just thought I'd show that I'm reading the messages. ;) Chris -)----- -- -- I have a shoehorn, the kind with teeth. -- --- Christopher R. Hertel -)----- University of Minnesota crh@nts.umn.edu Networking and Telecommunications Services From mhw at wittsend.com Wed Jun 9 21:39:28 1999 From: mhw at wittsend.com (Michael H. Warfield) Date: Tue Dec 2 03:03:05 2003 Subject: Do not use stock RedHat 6.0 kernels with SMBFS! In-Reply-To: from Alan Cox at "Jun 9, 1999 10:10:44 pm" Message-ID: <199906092139.RAA30461@alcove.wittsend.com> Alan Cox enscribed thusly: > > The real big problem is that the WIN95 workaround isnt a mount option. > > > > But it is. The bug is that the kernel has a CONFIG_SMB_WIN95 > Sorry I didnt mean this as in "it doesnt exist", but as in "its not > in the Red Hat file system tools or usable from there". Well, sort of... It is in the tools and it is usable. It's just not documented. If you've got smbmount, and can mount the partition, you can set the mount option using the previously mentioned hack setting the file permission sticky bit. > > that overrules the mount option. Just delete all mention of CONFIG_SMB_WIN95 > > from the kernel source (that is, from fs/Config.in, fs/smbfs/inode.c > > and Documentation/Configure.help, Documentation/filesystems/smbfs.txt) > > and all will be well. > I think this would be a good 2.3 patch. If I do this is anyone going to > scream ? I vote for that! Anyone who screams, we can give them the mount time option. > Alan Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From effugas at best.com Wed Jun 9 21:46:19 1999 From: effugas at best.com (Dan Kaminsky) Date: Tue Dec 2 03:03:05 2003 Subject: Do not use stock RedHat 6.0 kernels with SMBFS! In-Reply-To: from Alan Cox at "Jun 10, 99 07:23:05 am" Message-ID: <199906092146.OAA26492@shell3.ba.best.com> > I think this would be a good 2.3 patch. If I do this is anyone going to > scream ? > > Alan It's been reported that DOS attacks are feasable w/ the stock SMBFS configuration. If so, then we have a default-level break and it's a 2.2 fix, at least by the way *I* do my calculations. YMMV, unsurprisingly :-) Yours Truly, Dan Kaminsky DoxPara Research http://doxpara.netpedia.net From lnb at freedom.cybertouch.org Wed Jun 9 21:50:05 1999 From: lnb at freedom.cybertouch.org (Lanny Baron) Date: Tue Dec 2 03:03:05 2003 Subject: NT in Stand Alone mode and Samba Message-ID: Hello Fellow Samba users, I was told today my a teacher of MCSE that he thought the best thing with this PDC problem and rebooting of NT, then having to killall smbd and killall nmbd , is to just make NT a stand alone server and let Samba do the logons and passwd things. Has anyone tried it? Everytime I add something to NT and must reboot, I must quickly killall smbd and nmbd or else I can use NT for squat. Please mail me directly if at all possible. Thanks and have a great day!!! Lanny Baron (The master of DisASter) ---------------------------------- E-Mail: Lanny Baron Date: 09-Jun-99 Time: 17:44:49 This message was sent by XFMail ---------------------------------- From jallison at cthulhu.engr.sgi.com Wed Jun 9 21:49:33 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:05 2003 Subject: out of file structures References: <375E9AD8.3A010033@reac.com> <375E9C3A.C00F1D9C@engr.sgi.com> <375EDA3A.56556148@reac.com> Message-ID: <375EE16D.ECC41A51@engr.sgi.com> Andy Bakun wrote: > > I have reproduced it twice. Both times, it stopped in apparently the same place, > after copying a total of 1136 files and 246 directories. I had to copy that cd > twice in succession -- it would fail on the second time. The cd itself contains > 601 files and 136 directories. > No other SMB relation activities were going on on the client machine at the time. Thanks. Can you apply this patch (not really needed, it'll just help track the bitmap allocations) and then reproduce it again with a debug level 5 and then email the log to samba-bugs@samba.org and also directly to me. Thanks, Jeremy. Index: smbd/files.c =================================================================== RCS file: /data/cvs/samba/source/smbd/files.c,v retrieving revision 1.24.2.3 diff -r1.24.2.3 files.c 96a97 > 378,379c379,380 < DEBUG(5,("freed files structure %d (%d used)\n", < fsp->fnum, files_used)); --- > DEBUG(5,("freed files structure %d fnum = %d (%d used)\n", > fsp->fnum - FILE_HANDLE_OFFSET, fsp->fnum, files_used)); -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From bero at mandrakesoft.com Thu Jun 10 04:24:13 1999 From: bero at mandrakesoft.com (Bernhard Rosenkraenzer) Date: Tue Dec 2 03:03:06 2003 Subject: Do not use stock RedHat 6.0 kernels with SMBFS! In-Reply-To: <199906091531.LAA23286@alcove.wittsend.com> Message-ID: On Wed, 9 Jun 1999, Michael H. Warfield wrote: > Ok... I reported this problem to RedHat several days > ago, so they have had at least a small chance to look it over and > be ready for this announcement. I'm continuing to hear complaints > about corrupted timestamps on smbfs mounts so this word needs to > get out. We have had a look at the problem and noticed Mandrake 6.0 is affected, too. We've made fixed kernel RPMs available. They'll be available at ftp://sunsite.uio.no/pub/linux/Mandrake/updates/6.0/kernel*25mdk.i586.rpm and all other mirrors shortly (presently uploading). LLaP bero From mtrausch at wcnet.org Thu Jun 10 01:06:28 1999 From: mtrausch at wcnet.org (Michael B. Trausch) Date: Tue Dec 2 03:03:06 2003 Subject: Do not use stock RedHat 6.0 kernels with SMBFS! In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 9 Jun 1999, Stephen Langasek wrote: > > This is all the more important an issue because it affects those novice > users who don't know how to recompile their kernel to fix the problem, or > those large installations who don't have time to do so on all their > machines. The fact that the default kernel needs to be general-purpose and > non-optimized is no excuse for it to be broken... > One of the things that I found is that I learned to recompile the kernel when I had to upgrade my 2.0.36 kernel in Red Hat 5.2 to the 2.2.x series so that I could make use of my Zip Plus drive... 2.0.36 bombed with an Oops everytime I tried to access it - whereas, 2.2.x didn't. Eventually, everyone will have to learn it, IMHO. Unless they're willing to pay for someone else to do it. I've already had clients that have called me just for that purpose - they want to upgrade something on their system. Thing is that it *does* get expensive, and so what I do is if they want to learn how to do it themselves, I offer to teach them so that they don't have to call me out all the time... But there are the few that don't mind letting their pocketbooks do the thinking for them. They refuse to learn, so they force themselves to call me (or someone else). Currently, I'm the only Linux computer dude that I know of in my area - everyone else works with Windows or the Macintosh (I do them, too, but I don't advertise it as much as I do servicing Linux.) - ------------------------------------------------------------------------ Michael B. Trausch President of Linux Operations, ADK Computers http://adk.hypermart.net/ - ------------------------------------------------------------------------ PGP Public Key is available at a Key Server near you, or at: http://wcnet.org/~mtrausch/pubkey.txt - ------------------------------------------------------------------------ ADK Computers, Walbridge Office E-Mail: mtrausch@wcnet.org - ------------------------------------------------------------------------ To fall in love is to create a religion that has a fallible god. - JLB Life is a comedy for those who think and a tragedy for those who feel. Love is friendship set on fire. - French Proverb Customer: I'm running Windows '98 Tech: Yes. Customer: My computer isn't working now. Tech: Yes, you said that. -----BEGIN PGP SIGNATURE----- Version: GnuPG v0.9.7 (GNU/Linux) Comment: Made with PGP4Pine iD8DBQE3Xw+WBtYAauOptokRAoxPAJ9vhGmAumaoDCWX95iV+OXCyuP9wACfQW90 x4WE2kMVBXFmDrkT1RuD8O0= =JPBG -----END PGP SIGNATURE----- From jon at project.net.au Thu Jun 10 04:49:01 1999 From: jon at project.net.au (Jon Hilton) Date: Tue Dec 2 03:03:06 2003 Subject: nt_transact_ioctl and Project 98 Message-ID: <375F43BD.F759D3AA@project.net.au> Hi, I'm using MS Project 98 on Windows NT 4.0 WS sharing files from samba 2.0.4 on Linux Redhat 5.2. When I try to open multiple project files, Project ignores the file open request for the second file. An excerpt from the relevant log file is: log.devel2:[1999/06/10 14:04:40, 0] smbd/nttrans.c:call_nt_transact_ioctl(1491) log.devel2: call_nt_transact_ioctl: Currently not implemented. The relevant source seems to be (from smbd/nttrans.c in the current cvs tree): /**************************************************************************** Reply to IOCTL - not implemented - no plans. ****************************************************************************/ static int call_nt_transact_ioctl(connection_struct *conn, char *inbuf, char *outbuf, int length, int bufsize, char **ppsetup, char **ppparams, char **ppdata) { static BOOL logged_message = False; if(!logged_message) { DEBUG(0,("call_nt_transact_ioctl: Currently not implemented.\n")); logged_message = True; /* Only print this once... */ } return(ERROR(ERRSRV,ERRnosupport)); } At the moment this means that I can't use my Samba server to keep multiple project files under Project 98. I'm concerned about the "no plans" bit, though.... Who can I sweet talk? I am quite happy to help provide information and to test/debug but I don't know the internals of samba or NT well enough to try and take this on. Any takers?? Jon Hilton Project Net From tridge at samba.org Thu Jun 10 08:35:21 1999 From: tridge at samba.org (Andrew Tridgell) Date: Tue Dec 2 03:03:06 2003 Subject: Do not use stock RedHat 6.0 kernels with SMBFS! In-Reply-To: <199906092035.QAA29079@alcove.wittsend.com> (mhw@wittsend.com) References: <199906092035.QAA29079@alcove.wittsend.com> Message-ID: <19990610083530Z12861071-11226+408@samba.anu.edu.au> What really needs to be done is to rework the smbfs code to use the new clientgen SMB client library from Samba 2.0. The smbfs code is based on a very old version of smbclient and has all sorts of problems as a result. The new clientgen code auto-detects these sorts of server bugs and does the right thing. That's why the new smbclient works reliably with both Win95 and WinNT servers (if it doesn't then let me know, I spent quite a lot of time testing to make sure it does but I may have missed a case). After I start work for LinuxCare in September then maybe I could look at re-doing smbfs in terms of the clientgen code, but I certainly won't have time to do it until then. Too many exams/assignments to mark and 4 conferences to write papers for. Meanwhile, I think a quick fix would be to: - use info level 260 for all servers that have protocol level >= NT1 (that includes NT, W95 and Samba). - use info level 1 for other servers - add the code from cliengen.c that checks for a a failed TRANS2_FIND_* call and retries after a 200ms sleep (with a max loop count). That's needed for W95 servers as they sometimes fail to respond to the first request. The two routines that need changing are both in smbfs/proc.c and are smb_proc_readdir_long() and smb_decode_long_dirent(). They need to be hacked to behave move like the cli_list() and interpret_long_filename() routines from clientgen.c in Samba 2.0. With those changes we wouldn't need that flag at all. Cheers, Tridge From davecb at canada.sun.com Thu Jun 10 13:47:00 1999 From: davecb at canada.sun.com (David Collier-Brown) Date: Tue Dec 2 03:03:06 2003 Subject: The SND/RCV LO/HI WAT options References: Message-ID: <375FC1D4.960CF9E1@canada.sun.com> Majid Tajamolian wrote: > > > I'm working on SAMBA performance enhancement. Can anyone guide me for a > > > reference about the 4 WATer mark socket options and their effects on > > > TCP/IP performance? > > > Have anyone any experiments about using them in the SAMBA code? I asked: > > A colleague has been experimenting with them in a non-samba > > context, and we've been looking at their behavior quantiatively: > > Alas, I'm not doing the experiments myself... > > > > What would you like to know? > > > It seems that anything about them can be useful (i.e. their meaning, how > they change the TCP behavior, what is relation between them and the other > configurations such as SNDBUF, RCVBUF, , ...). > If you don't know about them, can you help me to find some information in > the internet? The best reference is Stevens' TCP/IP Illustrated, and a colleague and I have been playing with the high- and low-water marks in a group of Solaris servers and clients on 100baseT ethernet. Let's look at in /net3 terms (BSD & Linux): On the send side, an application writes a big chunk of data, say 10 KB. The so_send processing hands this off in 2048-byte mbufs to the lower level of the protocol, until there is enough data sent but not acknowledged to exceed the high-water mark, which is at 8k. At this point the sending stops until some acks come in. The sending process is suspended. The process is not awakened until the send-but-unacked data falls below the low-water mark, 2 KB. At this point it send the next two KB and is done for the moment. In a large-data scenario (which is what I have at work), you want the high-water mark to be set high enough that 1) the expected write size is below the high-water mark (minimum), and 2) the mark is high enough that enough data will be transferred and ack's on back-to-back writes that there will be at least a write's worth of space left below the high-water mark (optimum) Lets assume Samba is being used to access big database relations, and max xmit is at it's default setting of 65,535. Logically, you'd 1) want the high-water-mark set above 64 KB That's easy: the /net3 maximum is 26,2144. (The Solaris maximum is different, and affects the TCP scaling options) 2) want there to be at least 64KB free during back-to-back transfers. This is harder: you'll have to measure to see how fast samba can issue transfers back-to-back (by adding some timers), then compute how much data your ethernet transfers in the same period and then set the high-water mark to suit. Richards talks about the bandwidth-delay product: this is another issue affected by it. If you don't want to go the analytic route, you can just do experiments and plot high-water mark -vs- throughput. A test with no load on the ethernet will give you a curve that **underestimates** the buffering needed. Do your benchmarking in a production environment, in a busy period! If you can't I'd use a packet sniffer (snoop, in my case) to see what your "normal" load is, then run a bunch of ftp jobs on another pair of machines to simulate it on your test net. I'd expect the curve to look like this _____ ___/ ---__ _/ / / | | +------+-------+---- 0 default lots In other words, the performance when it's small would be badly throttled. When it's "enough" performance will jump up quickly, rise slowly to a peak and then drop off when big buffers starve other parts of the system for memory. The gentle curve at the top of the graph is caused by probabilistic effects: every once in a while, there's a burst of traffic, Samba doesn't get enough transferred in time and the the process hits the high-water mark and is suspended until the data drains. Add a bit more buffer and the probability is reduced. In my opinion, the important thing to know is where the performance jumps upward, measured on 10 mbit/sec ethernet for low, "average" and near-saturation loads. THAT curve is interesting to someone doing performance tuning, as it will tell them what's the minimum they must have what they need in the worst case, and the shape of the curve between those points. A concave curve means you can be low without much risk: a convex one means you'd better get as close to the maximum as you can. One known good point is the default: it's known to be sane for 10 mbit/sec ethernets and ftp sending 24-odd-KB worth of buffers. For 100, we don't need quite as much as the net acks data faster. For T1 and below, I have to ask a non-simulated guru! --dave -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | http://java.science.yorku.ca/~davecb Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb@canada.sun.com From davecb at canada.sun.com Thu Jun 10 14:17:30 1999 From: davecb at canada.sun.com (David Collier-Brown) Date: Tue Dec 2 03:03:06 2003 Subject: The SND/RCV LO/HI WAT options References: <375FC1D4.960CF9E1@canada.sun.com> Message-ID: <375FC8FA.FCFF8D98@canada.sun.com> David Collier-Brown wrote: > 1) want the high-water-mark set above 64 KB > That's easy: the /net3 maximum is 26,2144. Make that 262,144 --dave From lkcl at switchboard.net Thu Jun 10 16:21:15 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:06 2003 Subject: Do not use stock RedHat 6.0 kernels with SMBFS! In-Reply-To: <19990610083530Z12861071-11226+408@samba.anu.edu.au> Message-ID: richard sharpe's smblib also needs an update / merge with clientgen. On Thu, 10 Jun 1999, Andrew Tridgell wrote: > What really needs to be done is to rework the smbfs code to use the > new clientgen SMB client library from Samba 2.0. The smbfs code is > based on a very old version of smbclient and has all sorts of problems > as a result. The new clientgen code auto-detects these sorts of server > bugs and does the right thing. That's why the new smbclient works > reliably with both Win95 and WinNT servers (if it doesn't then let me > know, I spent quite a lot of time testing to make sure it does but I > may have missed a case). > > After I start work for LinuxCare in September then maybe I could look > at re-doing smbfs in terms of the clientgen code, but I certainly > won't have time to do it until then. Too many exams/assignments to > mark and 4 conferences to write papers for. > > Meanwhile, I think a quick fix would be to: > > - use info level 260 for all servers that have protocol level >= NT1 > (that includes NT, W95 and Samba). > > - use info level 1 for other servers > > - add the code from cliengen.c that checks for a a failed > TRANS2_FIND_* call and retries after a 200ms sleep (with a max loop > count). That's needed for W95 servers as they sometimes fail to > respond to the first request. > > The two routines that need changing are both in smbfs/proc.c and are > smb_proc_readdir_long() and smb_decode_long_dirent(). They need to be > hacked to behave move like the cli_list() and > interpret_long_filename() routines from clientgen.c in Samba 2.0. > > With those changes we wouldn't need that flag at all. > > Cheers, Tridge > Luke Kenneth Casson Leighton Samba and Network Development Samba Web site ===================================================================== Luke Kenneth Casson Leighton | Direct Dial : (678) 443-6183 Systems Engineer / ISS XForce Team | ISS Front Desk: (678) 443-6000 Internet Security Systems, Inc. | ISS Fax : (678) 443-6477 http://www.iss.net/ *Adaptive Network Security for the Enterprise* ISS Connect - International User Conference - May '99 ===================================================================== From caesmb at lab2.cc.wmich.edu Thu Jun 10 18:21:09 1999 From: caesmb at lab2.cc.wmich.edu (CAE Samba Admin) Date: Tue Dec 2 03:03:06 2003 Subject: new parameter: "secure include" Message-ID: Hello, I know that samba-ntdom probably isn't the best place for this message; however, I am not subscribed to samba-technical (nor do I want to be at the moment). I'm CC'ing this message over to samba-technical, so anyone reading over there, please mail me directly as well as mailing the list. Okay with that formaility out of the way, let me describe what I've done and why I did it. I'm running in a samba domain (PDC, yes I know, please don't tell me not to run the 2.0.x branch) where we are trying to get a setup where multiple departments will all use the PDC for authentication, but would like some control over the configuration. Using a %m substitution with an "include" in the smb.conf file would be a nice way to do this. We could just have directories coresponding to the machine accounts and then have an additional conf file in there with departmental override options. Unfortunately, this is a huge security risk. Just think about the possibilities of someone stuck a root preexec in their conf file. Here's my solution. All department config files must be "root approved". IOW, only root can actually change the files. Departments submit changes they want made to the sysadmin for review. Now, instead of a config file in the machine directories, we symlink to something like "/usr/local/samba/lib/smb_global-dept.conf" and through smb.conf like below: [global] secure include = /home/machines/%m/globals.conf Of course /home/machines/%m/globals.conf is a symlink to /usr/local/samba/lib/smb_global-dept.conf. The actual config file is owned by root and only writable by root. I basically copied the "handle_include" function in param/loadparm.c and made a "handle_secure_include" function which refuses to include the file of any of the following three conditions (in this order) aren't met: 1. root must own the file 2. the file must not be group writable 3. the file must not be world writable I've attached a diff against samba-2.0.4b below. I would really like to see this incorporated into future releases. I have some concerns about my coding ability though. Can someone check and make sure there are no gaping holes in my code or any loss of portability? I am especially concerned about systems where root uid != 0 (do any exist?). What would be a better way of checking than I am doing now? Thanks, Kevin Currie CAE Center Western Michigan University -------------- next part -------------- diff -uNr samba-2.0.4b/source/param/loadparm.c samba-2.0.4b-kgc/source/param/loadparm.c --- samba-2.0.4b/source/param/loadparm.c Mon May 17 19:37:24 1999 +++ samba-2.0.4b-kgc/source/param/loadparm.c Thu Jun 10 13:51:52 1999 @@ -261,6 +261,7 @@ char *szAdminUsers; char *szCopy; char *szInclude; + char *szSecureInclude; char *szPreExec; char *szPostExec; char *szRootPreExec; @@ -356,6 +357,7 @@ NULL, /* szAdminUsers */ NULL, /* szCopy */ NULL, /* szInclude */ + NULL, /* szSecureInclude */ NULL, /* szPreExec */ NULL, /* szPostExec */ NULL, /* szRootPreExec */ @@ -452,6 +454,7 @@ /* prototypes for the special type handlers */ static BOOL handle_valid_chars(char *pszParmValue, char **ptr); static BOOL handle_include(char *pszParmValue, char **ptr); +static BOOL handle_secure_include(char *pszParmValue, char **ptr); static BOOL handle_copy(char *pszParmValue, char **ptr); static BOOL handle_character_set(char *pszParmValue,char **ptr); static BOOL handle_coding_system(char *pszParmValue,char **ptr); @@ -784,6 +787,7 @@ {"-valid", P_BOOL, P_LOCAL, &sDefault.valid, NULL, NULL, FLAG_HIDE}, {"copy", P_STRING, P_LOCAL, &sDefault.szCopy, handle_copy, NULL, FLAG_HIDE}, {"include", P_STRING, P_LOCAL, &sDefault.szInclude, handle_include, NULL, FLAG_HIDE}, + {"secure include", P_STRING, P_LOCAL, &sDefault.szSecureInclude, handle_secure_include, NULL, FLAG_HIDE}, {"exec", P_STRING, P_LOCAL, &sDefault.szPreExec, NULL, NULL, FLAG_SHARE|FLAG_PRINT}, {"preexec", P_STRING, P_LOCAL, &sDefault.szPreExec, NULL, NULL, 0}, {"postexec", P_STRING, P_LOCAL, &sDefault.szPostExec, NULL, NULL, FLAG_SHARE|FLAG_PRINT}, @@ -1889,6 +1893,61 @@ } +/*************************************************************************** +handle the secure include operation +***************************************************************************/ +static BOOL handle_secure_include(char *pszParmValue,char **ptr) +{ + SMB_STRUCT_STAT istat; + + pstring fname; + pstrcpy(fname,pszParmValue); + + add_to_file_list(fname); + + standard_sub_basic(fname); + + string_set(ptr,fname); + + if (file_exist(fname,NULL)) { + + if (sys_stat(fname, &istat)) { + DEBUG(3,("ERROR: sys_stat failed on include file %s\n",fname)); + return(False); + } + else { + + // Ensure the file's uid == root + + if (istat.st_uid) { + DEBUG(2,("ERROR: secure include file %s uid not root\n",fname)); + return(False); + } + + // Make sure the file isn't group writable + + if (istat.st_mode & S_IWGRP) { + DEBUG(2,("ERROR: secure include file %s has group write bit set\n",fname)); + return(False); + } + + // Make sure the file isn't world writable + + if (istat.st_mode & S_IWOTH) { + DEBUG(2,("ERROR: secure include file %s has world write bit set\n",fname)); + return(False); + } + + return(pm_process(fname, do_section, do_parameter)); + } + } + + DEBUG(2,("Can't find include file %s\n",fname)); + + return(False); +} + + /*************************************************************************** handle the interpretation of the copy parameter ***************************************************************************/ From caesmb at lab2.cc.wmich.edu Thu Jun 10 18:45:53 1999 From: caesmb at lab2.cc.wmich.edu (CAE Samba Admin) Date: Tue Dec 2 03:03:06 2003 Subject: new parameter: "secure include" In-Reply-To: <3760059C.EDDF6E72@canada.sun.com> Message-ID: On Thu, 10 Jun 1999, David Collier-Brown wrote: >CAE Samba Admin wrote: >> 1. root must own the file >> 2. the file must not be group writable >> 3. the file must not be world writable > > Ditto the enclosing directories, up to the root must > be secure against my renaming the real directory and > shoving my version into place. The usual shortcut is > to do only the lowest-level directory, as if it's right > the others usually are. I understand the the loophole, but want to clarify the fix/shortcut (sorry, I'm not the most experianced unix programmer). If the actualy config file (not the symlink) is: /usr/local/samba/lib/smb_globals-dept.conf Then I should ensure that /usr/local/samba/lib meets the three conditions as well. Also, it is accepted that checking this directory alone (not everything before it) is secure? Thanks, Kevin From caesmb at lab2.cc.wmich.edu Thu Jun 10 18:55:27 1999 From: caesmb at lab2.cc.wmich.edu (CAE Samba Admin) Date: Tue Dec 2 03:03:06 2003 Subject: new parameter: "secure include" In-Reply-To: <199906101843.LAA01213@shell3.ba.best.com> Message-ID: >In the theme of what Andy and I are working on, it *MIGHT* be cleaner to >create an "include command" option that would offload permissions checking >/ live parameter generation to an arbitrary script. That way, *any* >security policy could be implemented. I do like that idea. Would you propose this in addition to "secure include"? My thinking is, have what the permissions I have now be the default, but if "include command" != NULL, then check those inside of "secure include" instead. I suppose I'd like someone to explain how "include" works a little better to me. Just from the source, it looks to be a "section" parameter and not a global. (am I correct?) My original intention was to have two "secure includes" in my smb.conf: one at the tail end of [globals] to override system wide stuff, and another at the end of the file to define additional shares. how would a "include command" fit into this in your mind? Thanks, Kevin BTW, for those reading... I am just about to go subscribe to samba-technical as well as samba-ntdom. From davecb at canada.sun.com Thu Jun 10 18:59:17 1999 From: davecb at canada.sun.com (David Collier-Brown) Date: Tue Dec 2 03:03:06 2003 Subject: new parameter: "secure include" References: Message-ID: <37600B05.8DAE302C@canada.sun.com> CAE Samba Admin wrote: > I understand the the loophole, but want to clarify the > fix/shortcut (sorry, I'm not the most experianced unix programmer). > > If the actualy config file (not the symlink) is: > > /usr/local/samba/lib/smb_globals-dept.conf > > Then I should ensure that /usr/local/samba/lib meets the three > conditions as well. Yes. > Also, it is accepted that checking this directory > alone (not everything before it) is secure? No, but it does catch the most common case. --dave From effugas at best.com Thu Jun 10 19:13:57 1999 From: effugas at best.com (Dan Kaminsky) Date: Tue Dec 2 03:03:06 2003 Subject: new parameter: "secure include" In-Reply-To: from CAE Samba Admin at "Jun 10, 99 02:55:27 pm" Message-ID: <199906101913.MAA00575@shell3.ba.best.com> > > >In the theme of what Andy and I are working on, it *MIGHT* be cleaner to > >create an "include command" option that would offload permissions checking > >/ live parameter generation to an arbitrary script. That way, *any* > >security policy could be implemented. > > I do like that idea. Would you propose this in addition to "secure > include"? My thinking is, have what the permissions I have now be the > default, but if "include command" != NULL, then check those inside of > "secure include" instead. My thinking is to *replace* secure include(which is a great stopgap) with a command that allows the admin to dynamically generate their includes and/or evaluate new includes. So, for example you could have only certain parameters allowed, certain groups, username that exists in an arbitrary text file, etc. This is all related to some new stuff I'm documenting up, so that's where this comes from. Basically, hardcoding things like "security" is very dependant on what one specific site defines as security... How many websites wish they could do "secure = 1" and be done with it... You could have as many include commands as you wanted, just as you can now. Might be some need to define what goes into each variable though. From caesmb at lab2.cc.wmich.edu Thu Jun 10 19:29:34 1999 From: caesmb at lab2.cc.wmich.edu (CAE Samba Admin) Date: Tue Dec 2 03:03:06 2003 Subject: new parameter: "secure include" References: <199906101913.MAA00575@shell3.ba.best.com> Message-ID: <003101beb377$92553390$1271da8d@wmich.edu> > My thinking is to *replace* secure include(which is a great stopgap) with > a command that allows the admin to dynamically generate their includes > and/or evaluate new includes. So, for example you could have only certain > parameters allowed, certain groups, username that exists in an arbitrary > text file, etc. Whoa! That is way out of my range of progamming cababilities (at least as far as integrating it into something as complex as samba). I was thinking something along the lines of: secure include = samba/lib/dept.conf, samba/scripts/dept.sh where samba/scripts/dept.sh is a bash (or perl, tcsh, whatever) script that returns where security clearance is met for samba/lib/dept.conf. That is probably within my abilities. :) > This is all related to some new stuff I'm documenting up, so that's where > this comes from. Basically, hardcoding things like "security" is very > dependant on what one specific site defines as security... Very true. From caesmb at lab2.cc.wmich.edu Thu Jun 10 19:31:13 1999 From: caesmb at lab2.cc.wmich.edu (CAE Samba Admin) Date: Tue Dec 2 03:03:06 2003 Subject: new parameter: "secure include" In-Reply-To: <37600B05.8DAE302C@canada.sun.com> Message-ID: >> >> Then I should ensure that /usr/local/samba/lib meets the three >> conditions as well. > Yes. I noticed that samba defines a whole lot of wrappers around standard C stuff to accomodate for differences between platforms. Are you aware of any functions that are used to traverse a pathname backwards like needs to be done? I'm not seeing any offhand, but I have to imagine this is done elseware in the source. Kevin From Wolfgang_Albrecht at gmx.de Thu Jun 10 19:31:52 1999 From: Wolfgang_Albrecht at gmx.de (Wolfgang Albrecht) Date: Tue Dec 2 03:03:06 2003 Subject: Dos find next file doesn't work on Samba 2.0.3 Message-ID: <8003.929043112@www3.gmx.net> Hi, there is a compatibility problem using Dos apps on a Win 95 machine with a Linux server. I have 3 Dos apps in my office, that work fine on C:, on a Novell server and on a NT server. But they don`t work on a Samba server. I`m using Samba 2.0.3 and Kernel 2.2.5 (Suse 6.1). I`ve tried to understand what is going wrong. The applications enter a subdirectory, try to find out which files are in that subdirectory and show them on screen. E. g., those applications do that in a subdirectory containing printer drivers. They search for files matching "????????.DT". If I use it on C: or on a Novell server, with a lot of files in that directory, they say they find the following files: NEC.DT EPSON.DT and so on.... On the Samba server, those applications say they find the following: NEC.DT That`s all. The applications do some other searches in other subdirectories, and they always find only the first entry. I`ve tried to analyse the logfile, and I talked to the developers of that applications. As far as I can see, the following happens: Application looks for "????????.DT" using the findfirst-call (function 4EH). Server sends "NEC.DT". Applications uses the findnext-call (function 4FH). Server (except Samba) sends "EPSON.DT". Samba-server seems to look if there is a second file named "NEC.DT" and returns that there are no more files. Since these apps work fine on all other network operating systems, I think this is a bug in Samba. It would be fine if it could be fixed. The developers of those Dos applications said they will write a little demo-program which will look for files in the way described above. This demo will be free of copyrights, so I can give it to anyone for testing purposes. They said they will do so next week. If anyone can fix this problem (sorry, but I can`t), please let me know. If you need this demo-program, please send me a mail, I will send the program to you as soon as I can. Thanks in advance, -- Sent through Global Message Exchange - http://www.gmx.net From jallison at cthulhu.engr.sgi.com Thu Jun 10 19:42:56 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:06 2003 Subject: Dos find next file doesn't work on Samba 2.0.3 References: <8003.929043112@www3.gmx.net> Message-ID: <37601540.8C188F61@engr.sgi.com> Wolfgang Albrecht wrote: > I`m using Samba 2.0.3 and Kernel 2.2.5 (Suse 6.1). > > Since these apps work fine on all other network operating systems, I think > this is a bug in Samba. It would be fine if it could be fixed. > > The developers of those Dos applications said they will write a little > demo-program which will look for files in the way described above. This > demo will be free of copyrights, so I can give it to anyone for testing > purposes. They said they will do so next week. If anyone can fix this > problem (sorry, but I can`t), please let me know. If you need this > demo-program, please send me a mail, I will send the program to you > as soon as I can. Can you check this on 2.0.4b please. There were some changes that went on in this area between 2.0.3 and 2.0.4 so it may already be fixed. Regards, Jeremy Allison, Samba Team. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From grant at 01019freenet.de Thu Jun 10 21:14:41 1999 From: grant at 01019freenet.de (Grant Wallace) Date: Tue Dec 2 03:03:06 2003 Subject: Samba 2.1 Message-ID: <37602AC1.5F28BD2E@01019freenet.de> Hi, Can anyone tell me, when the next official Samba version will be released? Grant From Tim.Potter at anu.edu.au Thu Jun 10 23:31:21 1999 From: Tim.Potter at anu.edu.au (Tim Potter) Date: Tue Dec 2 03:03:06 2003 Subject: bug found in password caching code in HEAD branch Message-ID: <14176.19145.91953.999935@acronym.anu.edu.au> Heh. This was annoying me for a while - samba was regularly bombing out trying to free() the pw_passwd entry from the password cache as it was being replaced by a string not produced by malloc, hence the crash. The culprit is the blocks of code in passdb/pass_check.c:pass_check() that fetch the shadow password #ifdef GETSPWNAM. The blocks #ifdef HAVE_GETPRPWNAM || #ifdef OSF1_ENH_SEC getprpwnam(), and #ifdef ULTRIX_AUTH getauthuid() will also cause a crash but I don't have access to any machines with manual pages for these functions. (-: I propose to either put a bunch of free() and strdup() functions in appropriate places in the pass_check() function, or to move all this stuff into the password caching code. The former may be confusing as there is no obvious reason why things should be free()ed, but the latter may have a big performance hit when refreshing the cache. I've also made lib/username.c:Get_Pwnam() return a const struct passwd * so the compiler will flag any attempt by someone changing the values in the password cache and creating this bug again. I initially did this to find any more occurrences of the bug I'm seeing (let the compiler find the bugs for you!) but I thought it might be a good idea to leave it in there. Anyone have any philosophical objections in general to const? Tim. -- Tim Potter, System Admin/Programmer, Head Bee Guy Advanced Computational Systems CRC, RSISE Bldg Australian National University, Canberra 0200, AUSTRALIA Ph: +61 2 62798813 Fax: +61 2 62798602 From mayfield at sackheads.org Fri Jun 11 13:42:21 1999 From: mayfield at sackheads.org (Jimmie Mayfield) Date: Tue Dec 2 03:03:06 2003 Subject: Potential problem or user error? Message-ID: <19990611064221.A3907@sackheads.org> Hi. I'm new to the list but haven't seen this mentioned in the archives... I recently upgraded one of our Samba servers from 2.0.0beta5 to 2.0.4b and started seeing problems running certain apps under Windows NT when the current directory is set to the Samba drive. The programs that fail seem to be limited to 16-bit OS2 programs. Don't laugh...some developers around here insist on using them and some are proprietary utilities that I can't find the source to. Anway, I have read about the problems regarding 16-bit apps and non-8.3 directories and I don't think that applies here. In my case, I'm in the 'root' directory on the samba drive when I try to execute the program and nothing in that directory has a filename over 8 bytes long (no extensions). I see a variety of problems no doubt related to how well the program was written. Some crash with an "OS2 exception", others like grep.exe simply return as if there were no files to search. Granted I can rebuild the grep program (and indeed I should) but the others I cannot. This problem did not occur with 2.0.0beta5. The smbd in question is running under AIX 4.3.2. The only build options specified were to enable syslog logging. Any suggestions? In the meantime, I've gone back to running 2.0.0beta5. Jimmie -- Jimmie Mayfield http://www.sackheads.org/mayfield email: mayfield+usenet@sackheads.org My mail provider does not welcome UCE -- http://www.sackheads.org/uce From Piet.Ruyssinck at rug.ac.be Fri Jun 11 15:12:38 1999 From: Piet.Ruyssinck at rug.ac.be (Piet Ruyssinck) Date: Tue Dec 2 03:03:06 2003 Subject: LDAP support sucks big time In-Reply-To: <19990531103322.D23315@callisto.rug.ac.be>; from Piet Ruyssinck on Mon, May 31, 1999 at 06:35:14PM +1000 References: <19990531103322.D23315@callisto.rug.ac.be> Message-ID: <19990611171238.H26414@callisto.rug.ac.be> On Mon, May 31, 1999 at 06:35:14PM +1000, Piet Ruyssinck wrote: > Hello, > > I just subscribed to this mailing list primarily as a means to vent my > frustration regarding the so called LDAP support in the samba-2.0.4b > source tree. This 'code' is a big joke, full of syntax errors even. > It is completely unuseable and had better been removed from the > distribution. > > Since I badly need LDAP support, the only thing I can do is rewrite the > code myself. I was wondering if the 'API' by which the 'modules' in > samba-2.0.4b/source/passdb are plugged into the rest of the code is a > static one or whether it is still being changed from release to release > ? It would be nice to know that I don't have to revise my code with > every new release of Samba. And while I'm on the topic, there wouldn't > happen to be a document available describing this API, would it ? I rewrote the module so that it fits my needs and so that it works. For those who might be interested, the code is freely available at http://diamond.rug.ac.be/ -- -------------------------------------------------------- Piet RUYSSINCK Piet.Ruyssinck@rug.ac.be Unix Systeem Administratie +32 9 264 4733 ACADEMISCH REKENCENTRUM (ARC) Universiteit Gent (RUG) Krijgslaan 281, gebouw S9, bureel 4 9000 Gent, Belgie From lkcl at switchboard.net Fri Jun 11 18:48:44 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:06 2003 Subject: bug found in password caching code in HEAD branch In-Reply-To: <14176.19145.91953.999935@acronym.anu.edu.au> Message-ID: > to leave it in there. Anyone have any philosophical objections in > general to const? no, go for it: const is good. it would be excellent if you could fix this hash code. From lkcl at switchboard.net Fri Jun 11 19:17:48 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:06 2003 Subject: ldap support written for 2.0.4b In-Reply-To: <19990611171238.H26414@callisto.rug.ac.be> Message-ID: > I rewrote the module so that it fits my needs and so that it works. > For those who might be interested, the code is freely available at > > http://diamond.rug.ac.be/ piet, thank you very much. please could you consider writing it to be compatible with cvs main branch. if you can do this i will commit both sets of patches into the respective source repositories, immediately. much appreciated, luke p.s i thought we had flamed that thankless-samba-newbie-ldap-knowall out of existence. does anyone know a good email exorcist? From ekuiperba at cc.curtin.edu.au Fri Jun 11 19:26:13 1999 From: ekuiperba at cc.curtin.edu.au (Beau Kuiper) Date: Tue Dec 2 03:03:06 2003 Subject: bug found in password caching code in HEAD branch References: Message-ID: <99061203290901.14446@darkstar> On Sat, 12 Jun 1999, Luke Kenneth Casson Leighton wrote: > > to leave it in there. Anyone have any philosophical objections in > > general to const? > > no, go for it: const is good. it would be excellent if you could fix this > hash code. I may be on weed or something, but it feels wrong to me that we solve the password lookup problem with a hash table. Why doesn't the samba code do the password lookup once, and then remember that entry for any further info, instead of issue the password lookup multiple times? Beau Kuiper ekuiperba@cc.curtin.edu.au From caesmb at lab2.cc.wmich.edu Fri Jun 11 20:04:35 1999 From: caesmb at lab2.cc.wmich.edu (CAE Samba Admin) Date: Tue Dec 2 03:03:06 2003 Subject: update: secure include Message-ID: Hello, I've added quite a bit more security to "secure include" as per suggestions of a few people here (thanks). This still isn't dynamic, sorry... But it does function as a nice absolute security (ie, root and only root). I've implemented verification of inodes, and I now perform the uid and write permission checks across the whole path up to the include file. I've included a diff against 2.0.4b below. I am still interested in seeing something like this integrated into the source trees, I'm also interested in cleaning this up for my own purposes. Any suggestions anyone could offer are welcome. I have a couple concerns as of now: ~ readlink() is called, but i don't think this function is POSIX. does anyone know of a POSIX way to do this? ~ root is assumed to be uid==0. is this true for all operating systems? ~ '/' is used in hacking apart the path is there a way to determine the directory seperator character for the OS? Again, any help making this conform to samba source standards will be appreciated. Thanks, Kevin Currie -------------- next part -------------- diff -uNr samba-2.0.4b/source/param/loadparm.c samba-2.0.4b-diff/source/param/loadparm.c --- samba-2.0.4b/source/param/loadparm.c Mon May 17 19:37:24 1999 +++ samba-2.0.4b-diff/source/param/loadparm.c Fri Jun 11 15:50:50 1999 @@ -261,6 +261,7 @@ char *szAdminUsers; char *szCopy; char *szInclude; + char *szSecureInclude; char *szPreExec; char *szPostExec; char *szRootPreExec; @@ -356,6 +357,7 @@ NULL, /* szAdminUsers */ NULL, /* szCopy */ NULL, /* szInclude */ + NULL, /* szSecureInclude */ NULL, /* szPreExec */ NULL, /* szPostExec */ NULL, /* szRootPreExec */ @@ -452,6 +454,7 @@ /* prototypes for the special type handlers */ static BOOL handle_valid_chars(char *pszParmValue, char **ptr); static BOOL handle_include(char *pszParmValue, char **ptr); +static BOOL handle_secure_include(char *pszParmValue, char **ptr); static BOOL handle_copy(char *pszParmValue, char **ptr); static BOOL handle_character_set(char *pszParmValue,char **ptr); static BOOL handle_coding_system(char *pszParmValue,char **ptr); @@ -784,6 +787,7 @@ {"-valid", P_BOOL, P_LOCAL, &sDefault.valid, NULL, NULL, FLAG_HIDE}, {"copy", P_STRING, P_LOCAL, &sDefault.szCopy, handle_copy, NULL, FLAG_HIDE}, {"include", P_STRING, P_LOCAL, &sDefault.szInclude, handle_include, NULL, FLAG_HIDE}, + {"secure include", P_STRING, P_LOCAL, &sDefault.szSecureInclude, handle_secure_include, NULL, FLAG_HIDE}, {"exec", P_STRING, P_LOCAL, &sDefault.szPreExec, NULL, NULL, FLAG_SHARE|FLAG_PRINT}, {"preexec", P_STRING, P_LOCAL, &sDefault.szPreExec, NULL, NULL, 0}, {"postexec", P_STRING, P_LOCAL, &sDefault.szPostExec, NULL, NULL, FLAG_SHARE|FLAG_PRINT}, @@ -1889,6 +1893,131 @@ } +/*************************************************************************** +handle the secure include operation +***************************************************************************/ +static BOOL handle_secure_include(char *pszParmValue,char **ptr) +{ + SMB_STRUCT_STAT init_stat, link_stat, test_stat; + int filedes; + + pstring fname, path, front; + pstrcpy(fname,pszParmValue); + + add_to_file_list(fname); + + standard_sub_basic(fname); + + string_set(ptr,fname); + + if (!(file_exist(fname,NULL))) { + DEBUG(2,("Can't find include file %s\n",fname)); + return(False); + } + + // preserve fname since split_to_last_component is destructive + + pstrcpy(front, fname); + + // check security of full path of secure include file + + do { + + // Get file stat info on filename, IOW: get the inode ASAP + + if (sys_stat(front, &init_stat)) { + DEBUG(2,("ERROR: sys_stat failed on secure include file/path %s\n",front)); + return(False); + } + + // Get link stat info on filename + + if (sys_lstat(front, &init_stat)) { + DEBUG(2,("ERROR: sys_lstat failed on secure include file/path %s\n",front)); + return(False); + } + + // If filename is a symlink, get the name of the file it points to + + if (S_ISLNK(link_stat.st_mode)) { + if (readlink(front, front, sizeof(pstring)) < 0) { + DEBUG(2,("ERROR: readlink failed on secure include file/path %s\n",front)); + return(False); + } + } + + // Make user the link isn't broken + // We don't use file_exist() here because we also process directories + + if (sys_stat(front, &link_stat)) { + DEBUG(2,("ERROR: secure include file/path %s is a broken link\n",front)); + return(False); + } + + // Open the file while doing security checks so that softlinks + // cannot be redirected on a bogged down system before the + // checks can occur + + filedes = sys_open(front, O_RDONLY, S_IRWXU); + if (filedes < 0) { + DEBUG(2,("ERROR: sys_open failed on secure include file/path %s\n",front)); + return(False); + } + + // Get stat info on the open file + + if (sys_fstat(filedes, &test_stat)) { + DEBUG(2,("ERROR: sys_fstat failed on secure include file/path %s\n",front)); + return(False); + } + + // Now that we have the info, close the file + + if (close(filedes)) { + DEBUG(2,("ERROR: close failed on secure include file/path %s\n",front)); + return(False); + } + + // Ensure we're at the same inode we started with + + if (init_stat.st_ino != test_stat.st_ino) { + DEBUG(2,("ERROR: secure include file/path %s inode changed during security checks\n",front)); + return(False); + } + + // Ensure the file's uid == root + + if (test_stat.st_uid) { + DEBUG(2,("ERROR: secure include file/path %s uid not root\n",front)); + return(False); + } + + // Make sure the file isn't group writable + + if (test_stat.st_mode & S_IWGRP) { + DEBUG(2,("ERROR: secure include file/path %s has group write bit set\n",front)); + return(False); + } + + // Make sure the file isn't world writable + + if (test_stat.st_mode & S_IWOTH) { + DEBUG(2,("ERROR: secure include file/path %s has world write bit set\n",front)); + return(False); + } + + pstrcpy(path, front); + split_at_last_component(path, front, '/', NULL); + + } while (*front != '\0'); + + // Okay, we made it. Go ahead and process the file + + return(pm_process(fname, do_section, do_parameter)); + +} + + /*************************************************************************** handle the interpretation of the copy parameter ***************************************************************************/ From lkcl at switchboard.net Fri Jun 11 21:25:07 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:06 2003 Subject: bug found in password caching code in HEAD branch In-Reply-To: <99061203290901.14446@darkstar> Message-ID: On Sat, 12 Jun 1999, Beau Kuiper wrote: > On Sat, 12 Jun 1999, Luke Kenneth Casson Leighton wrote: > > > to leave it in there. Anyone have any philosophical objections in > > > general to const? > > > > no, go for it: const is good. it would be excellent if you could fix this > > hash code. > > I may be on weed or something, but it feels wrong to me that we solve > the password lookup problem with a hash table. Why doesn't the samba > code do the password lookup once, and then remember that entry for > any further info, instead of issue the password lookup multiple times? same difference, if you ask me. this only became a problem when the unix <-> nt mapping code was added, due to the high number of unix password and unix group calls required. From dkrovich at wvu.edu Sat Jun 12 06:01:02 1999 From: dkrovich at wvu.edu (David Krovich) Date: Tue Dec 2 03:03:06 2003 Subject: smbpasswd password changing Message-ID: Running Samba 2.0.4b on Solaris 2.5.1 I can't get smbpasswd to change a password as a normal user. (I've allowed 127. in the hosts allow parameter in smb.conf) Some other notes: - root can change any users smb password using smbpasswd. - In the latest version of CVS that I tried on the same machine, (approx 2 weeks ago) using smbpasswd to change passwords as a normal user worked fine. Anyways, here is an attempted password changing session using smbpasswd with Debug Level set to 5. Can anyone help? If you need more info about my system let me know. ---begin--- doing parameter workgroup = WVUCSEENTDOMAIN doing parameter server string = Samba Server doing parameter hosts allow = 127.0.0.0/255.0.0.0, 157.182.194.0/255.255.255.0, 129.164.10.0/255.255.255.0, 157.182.80.0/255.255.255.0, 157.182.81.0/255.255.255.0, 157.182.82.0/255.255.255.0, 157.182.196.0/255.255.254.0 doing parameter log file = /sys/samba20/var/log.%m doing parameter max log size = 50 doing parameter security = user doing parameter encrypt passwords = yes doing parameter socket options = TCP_NODELAY doing parameter interfaces = 157.182.194.28/24 157.182.194.99/24 157.182.197.5/24 157.182.197.25/24 doing parameter domain logons = yes doing parameter logon path = \\%L\Profiles\%U doing parameter dns proxy = no doing parameter netbios name = WVUCSEEPDC doing parameter netbios aliases = WVUCSEE_HOME doing parameter unix password sync = true doing parameter include = /sys/samba20/lib/smb.conf.%L Can't find include file /sys/samba20/lib/smb.conf. pm_process() returned Yes load_client_codepage: loading codepage 850. Added interface ip=157.182.194.28 bcast=157.182.194.255 nmask=255.255.255.0 Added interface ip=157.182.194.99 bcast=157.182.194.255 nmask=255.255.255.0 Added interface ip=157.182.197.5 bcast=157.182.197.255 nmask=255.255.255.0 Added interface ip=157.182.197.25 bcast=157.182.197.255 nmask=255.255.255.0 Old SMB password: New SMB password: Retype new SMB password: Connecting to 127.0.0.1 at port 139 Sent session request size=0 smb_com=0x0 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=0 smb_flg2=0 smb_tid=0 smb_pid=0 smb_uid=0 smb_mid=0 smt_wct=0 smb_bcc=0 size=93 smb_com=0x72 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=0 smb_pid=15286 smb_uid=0 smb_mid=1 smt_wct=17 smb_vwv[0]=6 (0x6) smb_vwv[1]=12803 (0x3203) smb_vwv[2]=256 (0x100) smb_vwv[3]=65280 (0xFF00) smb_vwv[4]=255 (0xFF) smb_vwv[5]=0 (0x0) smb_vwv[6]=256 (0x100) smb_vwv[7]=46848 (0xB700) smb_vwv[8]=59 (0x3B) smb_vwv[9]=12544 (0x3100) smb_vwv[10]=3 (0x3) smb_vwv[11]=0 (0x0) smb_vwv[12]=46737 (0xB691) smb_vwv[13]=17989 (0x4645) smb_vwv[14]=48818 (0xBEB2) smb_vwv[15]=61441 (0xF001) smb_vwv[16]=2048 (0x800) smb_bcc=24 size=93 smb_com=0x72 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=0 smb_pid=15286 smb_uid=0 smb_mid=1 smt_wct=17 smb_vwv[0]=6 (0x6) smb_vwv[1]=12803 (0x3203) smb_vwv[2]=256 (0x100) smb_vwv[3]=65280 (0xFF00) smb_vwv[4]=255 (0xFF) smb_vwv[5]=0 (0x0) smb_vwv[6]=256 (0x100) smb_vwv[7]=46848 (0xB700) smb_vwv[8]=59 (0x3B) smb_vwv[9]=12544 (0x3100) smb_vwv[10]=3 (0x3) smb_vwv[11]=0 (0x0) smb_vwv[12]=46737 (0xB691) smb_vwv[13]=17989 (0x4645) smb_vwv[14]=48818 (0xBEB2) smb_vwv[15]=61441 (0xF001) smb_vwv[16]=2048 (0x800) smb_bcc=24 size=75 smb_com=0x73 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=0 smb_pid=15286 smb_uid=100 smb_mid=1 smt_wct=3 smb_vwv[0]=255 (0xFF) smb_vwv[1]=0 (0x0) smb_vwv[2]=1 (0x1) smb_bcc=34 size=75 smb_com=0x73 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=0 smb_pid=15286 smb_uid=100 smb_mid=1 smt_wct=3 smb_vwv[0]=255 (0xFF) smb_vwv[1]=0 (0x0) smb_vwv[2]=1 (0x1) smb_bcc=34 size=49 smb_com=0x75 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=1 smb_pid=15286 smb_uid=100 smb_mid=1 smt_wct=3 smb_vwv[0]=255 (0xFF) smb_vwv[1]=0 (0x0) smb_vwv[2]=1 (0x1) smb_bcc=8 size=633 smb_com=0x25 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=8 smb_flg2=1 smb_tid=1 smb_pid=15286 smb_uid=100 smb_mid=1 smt_wct=14 smb_vwv[0]=25 (0x19) smb_vwv[1]=532 (0x214) smb_vwv[2]=2 (0x2) smb_vwv[3]=0 (0x0) smb_vwv[4]=0 (0x0) smb_vwv[5]=0 (0x0) smb_vwv[6]=0 (0x0) smb_vwv[7]=0 (0x0) smb_vwv[8]=0 (0x0) smb_vwv[9]=25 (0x19) smb_vwv[10]=76 (0x4C) smb_vwv[11]=532 (0x214) smb_vwv[12]=101 (0x65) smb_vwv[13]=0 (0x0) smb_bcc=570 size=60 smb_com=0x25 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=1 smb_pid=15286 smb_uid=100 smb_mid=1 smt_wct=10 smb_vwv[0]=2 (0x2) smb_vwv[1]=0 (0x0) smb_vwv[2]=0 (0x0) smb_vwv[3]=2 (0x2) smb_vwv[4]=56 (0x38) smb_vwv[5]=0 (0x0) smb_vwv[6]=0 (0x0) smb_vwv[7]=60 (0x3C) smb_vwv[8]=0 (0x0) smb_vwv[9]=0 (0x0) smb_bcc=5 size=60 smb_com=0x25 smb_rcls=0 smb_reh=0 smb_err=0 smb_flg=136 smb_flg2=1 smb_tid=1 smb_pid=15286 smb_uid=100 smb_mid=1 smt_wct=10 smb_vwv[0]=2 (0x2) smb_vwv[1]=0 (0x0) smb_vwv[2]=0 (0x0) smb_vwv[3]=2 (0x2) smb_vwv[4]=56 (0x38) smb_vwv[5]=0 (0x0) smb_vwv[6]=0 (0x0) smb_vwv[7]=60 (0x3C) smb_vwv[8]=0 (0x0) smb_vwv[9]=0 (0x0) smb_bcc=5 Realloc asked for 0 bytes machine 127.0.0.1 rejected the password change: Error was : The specified password is invalid. Failed to change password for dkrovich ---end--- ----------------------------------------- David Krovich West Virginia University Manager/Information Systems Computer Science & Electrical Engineering ----------------------------------------- From Mattias.Gronlund at sa.erisoft.se Sat Jun 12 14:53:10 1999 From: Mattias.Gronlund at sa.erisoft.se (Mattias Gronlund) Date: Tue Dec 2 03:03:06 2003 Subject: Logfiles grow much bigger than they should Message-ID: <37627456.F8154337@epl.ericsson.se> Hi, We just noticed that there is a problem with samba and it's log-files. There is a function called "check_log_size" that starts with: if( debug_count++ < 100 || geteuid() != 0 ) return; And it just happens that some (a lot?) debug-messages get written with euid != 0. For example: [1999/06/12 15:29:04.514423, 0, 24668] lib/util_sock.c:write_data(416) write_data: write failure. Error = Disc quota exceeded We are using the default max-size of 5000KB for log-files. But our current log-sizes is: -rw-r--r-- 1 root root 355703 Jun 12 16:22 /var/log/log-180.smb -rw-r--r-- 1 root root 12557626 Jun 11 18:15 /var/log/log-180.smb.old and I have seen MUCH larger ones. There is also a problem with the log-switching, We have a server with 29 smbd-processes that writes an unlinked logfile. The log-file has been switched two times and some processes has newer followed the change. I don't have all that insigt in the Samba-source, for finding the right solution for the problem, so I would be happy if someone could give me a hint on which way to go for solving this problem. I think that one sulotion could be to change the to not change the log-file in the debug-call-chain, but insted set a flag that tha main loop could check for. The main-loop then could in a controlled way switch user to root to switch-log. It would also make it easyer to let the main-loop check the log-size say every 5 minits or so. This would also make idle (non log-writing) smbds to switch log (so the diskspace can be returned when unlinked). I didn't get any answers for my last mail, so if this is the wrong place for this type of discussion please feel free to tell me. /Mattias From Tim.Potter at anu.edu.au Sun Jun 13 04:06:59 1999 From: Tim.Potter at anu.edu.au (Tim Potter) Date: Tue Dec 2 03:03:06 2003 Subject: bug found in password caching code in HEAD branch In-Reply-To: References: <99061203290901.14446@darkstar> Message-ID: <14179.11875.724833.664010@acronym.anu.edu.au> Luke Kenneth Casson Leighton writes: > > I may be on weed or something, but it feels wrong to me that we solve > > the password lookup problem with a hash table. Why doesn't the samba > > code do the password lookup once, and then remember that entry for > > any further info, instead of issue the password lookup multiple times? > > same difference, if you ask me. this only became a problem when the unix > <-> nt mapping code was added, due to the high number of unix password and > unix group calls required. On a slightly different note, I notice the cache expiry time, PASSWD_HASH_AGE in username.c, is set to 15 seconds. Does this strike anyone as being a bit low? I mean the entire password database has to be re-read four times a minute. Unless your samba server is getting totally hammered, I don't think this is going to provide any serious optimisation. Tim. -- Tim Potter, System Admin/Programmer, Head Bee Guy Advanced Computational Systems CRC, RSISE Bldg Australian National University, Canberra 0200, AUSTRALIA Ph: +61 2 62798813 Fax: +61 2 62798602 From tridge at samba.org Sun Jun 13 05:52:20 1999 From: tridge at samba.org (Andrew Tridgell) Date: Tue Dec 2 03:03:06 2003 Subject: smbfs patches for Linux 2.2.9 In-Reply-To: (message from Alan Cox on Thu, 10 Jun 1999 07:22:55 +1000) References: Message-ID: <19990613055230Z12856028-9913+1025@samba.anu.edu.au> Alan, I found some time this afternoon to fixup smbfs in 2.2.9. The diff is available at ftp://samba.org/pub/tridge/misc/smbfs-patch-2.2.9.diff and is against 2.2.9. It fixes: - removes win95 bug workround option - auto-detects win95 servers and applies appropriate fixes - fixes debug code to work with dcache - fixes timezone handling (it was totally broken). It should now work and also handles cross-timezone mounts using the servers zone offset. - fixed file time setting to win95 servers - removed bogus \\ path prefix in setattr_core To get all the timezone fixes you should use the current smbmount CVS code from the SAMBA_2_0 branch (or our next released version) although it does attempt to detect an old smbmount and do the right thing (the old smbmount tried to squeeze the timezone in seconds into a 16 bit int, and it didn't fit for some zones) Will you propogate this to Linus or shall I? Cheers, Tridge From rune at lyngbyes.dk Sun Jun 13 11:36:09 1999 From: rune at lyngbyes.dk (Rune Henssel) Date: Tue Dec 2 03:03:06 2003 Subject: Help needed with new parameter Message-ID: <001501beb591$058c03a0$4b0210ac@tik.net> Hello! I am in the process of trying to write som new functionality into samba 2.0.4b. What I need is for samba to be able to show/hide selected shares based on the userid sending the request. At the moment I am solving the problem using multiple %U includes if smb.conf, but it is rather messy and dificult to maintain. Hence the need for at "visible to user" parameter. My problem is that I don't know where to place the code needed. Any help would be greatly appreciated. Rune! rune@lyngbyes.dk If among many truth you choose one and follow it blindly, it will become a falsehood and you a fanatic. From bje at cygnus.com Sun Jun 13 12:09:45 1999 From: bje at cygnus.com (Ben Elliston) Date: Tue Dec 2 03:03:06 2003 Subject: PROT_READ et al Message-ID: I just tried to compile Samba 2.0.4b on an oldish Slackware system with libc 5.x. Compiling locking/shmem.c failed because PROT_READ was undeclared. On my system, it lives in . Why is this not tracked down with the configure script? It seems like this would be rather platform specific. Ben -- Ben Elliston bje@cygnus.com From matty at samba.org Sun Jun 13 12:13:25 1999 From: matty at samba.org (Matt Chapman) Date: Tue Dec 2 03:03:06 2003 Subject: FW: 2.0.4b: unacceptable long browsing times from Windows2000 Beta3 References: <001201beb105$4bd389e0$21c9ca95@mow.siemens.ru> Message-ID: <3763A065.BF1ACCFB@samba.org> Andrej Borsenkow wrote: > > In Explorer, browse the network, double click on SAMBA server, than double > click on any share - it takes more than five minutes! till list of files in > this share appears! [to samba-technical] For the record Win2k calls NetrShareGetInfo when opening shares. -- Matthew "Austin" Chapman SysAdmin, Developer, Samba Team Member From matthew.cudworth at tait.co.nz Mon Jun 14 00:00:45 1999 From: matthew.cudworth at tait.co.nz (Matt Cudworth) Date: Tue Dec 2 03:03:06 2003 Subject: Useful Admin features Message-ID: <3764462C.B4D66950@tait.co.nz> Hi all, I have a large (500 client) network here with Samba running the show [Replaced Novell/NT]. There a couple of features that "should" be very easy to implement that would be extremely useful in a Corporate Environment. [1] Using the Samba logging it appears to be difficult to get an audit trail of who deleted what ? and when ?. Turning the logging level up degrades performance far too much when the deletion is the bit of interest. [2] Have a feature like Novell where you can specify per share a deleted file cache. This could be implemented quickly by changing the delete command to a move command. That would eliminate 99% of backup requests. Matt Cudworth Unix Sys Admin Tait Electronics Ltd, New Zealand +64 03 3583399 -------------- next part -------------- A non-text attachment was scrubbed... Name: matthew.cudworth.vcf Type: text/x-vcard Size: 361 bytes Desc: Card for Matt Cudworth Url : http://lists.samba.org/archive/samba-technical/attachments/19990614/588de9c5/matthew.cudworth.vcf From Piet.Ruyssinck at rug.ac.be Mon Jun 14 10:44:50 1999 From: Piet.Ruyssinck at rug.ac.be (Piet Ruyssinck) Date: Tue Dec 2 03:03:06 2003 Subject: ldap support written for 2.0.4b In-Reply-To: ; from Luke Kenneth Casson Leighton on Fri, Jun 11, 1999 at 08:17:48PM +0100 References: <19990611171238.H26414@callisto.rug.ac.be> Message-ID: <19990614124450.D19323@callisto.rug.ac.be> On Fri, Jun 11, 1999 at 08:17:48PM +0100, Luke Kenneth Casson Leighton wrote: > > I rewrote the module so that it fits my needs and so that it works. > > For those who might be interested, the code is freely available at > > > > http://diamond.rug.ac.be/ > > piet, > > thank you very much. please could you consider writing it to be > compatible with cvs main branch. if you can do this i will commit both > sets of patches into the respective source repositories, immediately. While browsing through the files in the cvs code tree, I discovered that the LDAP support code in there is pretty much OK now - unlike what I found in the 2.0.4b release. The only thing that might need to be changed from site to site is the ldap_getpw function in source/passdb/ldap.c because there's no real standard for samba LDAP attributes (or is there ?) Maybe, this function had better be lifted out of the ldap.c file and be put in a separate file (eg ldap_local.c) I will first try to make the best possible use of this existing module. Will the next release be based on this cvs branch ? -- -------------------------------------------------------- Piet RUYSSINCK Piet.Ruyssinck@rug.ac.be Unix Systeem Administratie +32 9 264 4733 ACADEMISCH REKENCENTRUM (ARC) Universiteit Gent (RUG) Krijgslaan 281, gebouw S9, bureel 4 9000 Gent, Belgie From greg at discreet.com Mon Jun 14 11:32:56 1999 From: greg at discreet.com (Greg Dickie) Date: Tue Dec 2 03:03:06 2003 Subject: Useful Admin features In-Reply-To: <3764462C.B4D66950@tait.co.nz> Message-ID: Uh... the answer is 3! How about you use one of those lo-tech email clients that actually work? Greg On 14-Jun-99 Matt Cudworth wrote: > This is a multi-part message in MIME format. > --------------CDFFB193C9A792ED0E24C25D > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: base64 > > SGkgYWxsLA0KDQpJIGhhdmUgYSBsYXJnZSAoNTAwIGNsaWVudCkgbmV0d29yayBoZXJlIHdp > dGggU2FtYmEgcnVubmluZw0KdGhlIHNob3cgW1JlcGxhY2VkIE5vdmVsbC9OVF0uIFRoZXJl > IGEgY291cGxlIG9mIGZlYXR1cmVzDQp0aGF0ICJzaG91bGQiIGJlIHZlcnkgZWFzeSB0byBp > bXBsZW1lbnQgdGhhdCB3b3VsZCBiZQ0KZXh0cmVtZWx5IHVzZWZ1bCBpbiBhIENvcnBvcmF0 > ZSBFbnZpcm9ubWVudC4NCg0KWzFdICBVc2luZyB0aGUgU2FtYmEgbG9nZ2luZyBpdCBhcHBl > YXJzIHRvIGJlIGRpZmZpY3VsdCB0byBnZXQNCiAgICAgIGFuIGF1ZGl0IHRyYWlsIG9mIHdo > byBkZWxldGVkIHdoYXQgPyBhbmQgd2hlbiA/LiBUdXJuaW5nDQogICAgICB0aGUgbG9nZ2lu > ZyBsZXZlbCB1cCBkZWdyYWRlcyBwZXJmb3JtYW5jZSBmYXIgdG9vIG11Y2gNCiAgICAgIHdo > ZW4gdGhlIGRlbGV0aW9uIGlzIHRoZSBiaXQgb2YgaW50ZXJlc3QuDQoNClsyXSBIYXZlIGEg > ZmVhdHVyZSBsaWtlIE5vdmVsbCB3aGVyZSB5b3UgY2FuIHNwZWNpZnkgcGVyIHNoYXJlDQog > ICAgIGEgZGVsZXRlZCBmaWxlIGNhY2hlLiBUaGlzIGNvdWxkIGJlIGltcGxlbWVudGVkIHF1 > aWNrbHkgYnkNCiAgICAgY2hhbmdpbmcgdGhlIGRlbGV0ZSBjb21tYW5kIHRvIGEgbW92ZSBj > b21tYW5kLiBUaGF0DQogICAgIHdvdWxkIGVsaW1pbmF0ZSA5OSUgb2YgYmFja3VwIHJlcXVl > c3RzLg0KDQpNYXR0IEN1ZHdvcnRoDQpVbml4IFN5cyBBZG1pbg0KVGFpdCBFbGVjdHJvbmlj > cyBMdGQsIE5ldyBaZWFsYW5kDQorNjQgMDMgMzU4MzM5OQ0KDQo= > --------------CDFFB193C9A792ED0E24C25D > Content-Type: text/x-vcard; charset=iso-8859-1; > name="matthew.cudworth.vcf" > Content-Transfer-Encoding: base64 > Content-Description: Card for Matt Cudworth > Content-Disposition: attachment; > filename="matthew.cudworth.vcf" > > YmVnaW46dmNhcmQgCm46Q3Vkd29ydGg7TWF0dAp0ZWw7aG9tZTorNjQgMDMgMzM3NTQ5OQp0 > ZWw7d29yazorNjQgMDMgMzU4MzM5OSAoRXh0IDg0NDEpCngtbW96aWxsYS1odG1sOlRSVUUK > dXJsOmh0dHA6Ly90YWl0d29ybGQuY29tCm9yZzpUYWl0IEVsZWN0cm9uaWNzIEx0ZAp2ZXJz > aW9uOjIuMQplbWFpbDtpbnRlcm5ldDptYXR0aGV3LmN1ZHdvcnRoQHRhaXQuY28ubnoKdGl0 > bGU6SVQgUHJvamVjdCBFbmdpbmVlcgphZHI7cXVvdGVkLXByaW50YWJsZTo7OzU1OCBXYWly > YWtpIFJkPTBEPTBBQnVybnNpZGU7Q2hyaXN0Y2h1cmNoOzs7TmV3IFplYWxhbmQKeC1tb3pp > bGxhLWNwdDo7MApmbjpNYXR0IEN1ZHdvcnRoCmVuZDp2Y2FyZAo= > --------------CDFFB193C9A792ED0E24C25D-- --------------------------------------------------------------------- Greg Dickie Just A Guy* *from discreet (the logic is gone) Montreal (514) 954-7171 greg@discreet.com From davecb at canada.sun.com Mon Jun 14 13:58:52 1999 From: davecb at canada.sun.com (David Collier-Brown) Date: Tue Dec 2 03:03:06 2003 Subject: The SND/RCV LO/HI WAT options References: <375FC1D4.960CF9E1@canada.sun.com> Message-ID: <37650A9C.159434FD@canada.sun.com> David Collier-Brown wrote: (far too much) Just an update: SO_SNDLOWAT sets the low water mark, but SO_SNDBUF set the high-water mark. The names don't match for purely historical reasons. The only other intersting socket options are TCP_MAXSEG, which can only **reduce** the packet size, useful for cases where all of: 1) the default is too big, 2) fragmentation is happening and 3) the link is lossy are true... max xmit = 65,535, so it won't limit this... This means the numbers reported here many moons ago (graph attached) are intersting: they're from a previous experiment on an older linux machine. The twitch in writes is odd: perhaps your work will help me figure it out. Feel free to email. --dave -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | http://java.science.yorku.ca/~davecb Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb@canada.sun.com -or- David Collier-Brown, | Always do right. This will gratify some Performance & Arch. | people and astonish the rest. -- Mark Twain Sun Canada (Opcom) | davecb@canada.sun.com (905) 477-0437 | http://elsbeth.canada.sun.com/~davecb $ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0902.gif Type: image/gif Size: 4685 bytes Desc: not available Url : http://lists.samba.org/archive/samba-technical/attachments/19990614/96e04623/0902.gif From timothy_d_cole at md.northgrum.com Mon Jun 14 16:24:19 1999 From: timothy_d_cole at md.northgrum.com (Cole, Timothy D.) Date: Tue Dec 2 03:03:06 2003 Subject: FW: patch for safer/saner permissions setting Message-ID: <51FBD4A8EFD9D111BA7300A0C927DADB563086@xcgmd008.md.essd.northgrum.com> I originally sent this to samba-bugs, but didn't see any response... apologies if this has already hit CVS in some form or another; I can't use CVS from behind the firewall, and the samba-cvs archives seem to be b0rked as well. --- begin forwarded message --- > I've been playing with the permissions setting in 2.0.4 from an NT client, > and I'm finding that: > > 1. most of the time you want to allow the user to set permissions > broader than the creation mask if they want > > 2. existing permission bits always get silently mangled (by the creation > mask and the forced mode, as well as suid/sgid/sticky bits being > stripped), even when the user doesn't explicitly change them. This can be > downright _dangerous_ in some cases, particularly with force mode > > The attached patch (against 2.0.4, although it should apply to 2.0.4b > fine) addresses the first issue by adding "allow mask" and "allow > directory mask" configuration parameters (defaulting to 0000), which are > ored with the creation mask when determining what permission bits the user > can set (so, if she desires, the sysadmin can allow users to set a more > liberal permissions than allowed by the creation mask alone). The patch > also allows Samba to preserve any permission bits that the user hasn't > directly modified. > --- snip --- diff -u3 -r samba-2.0.4.orig/source/include/proto.h samba-2.0.4/source/include/proto.h --- samba-2.0.4.orig/source/include/proto.h Mon May 17 19:27:59 1999 +++ samba-2.0.4/source/include/proto.h Tue Jun 1 11:50:24 1999 @@ -1152,8 +1152,10 @@ BOOL lp_mangle_locks(int ); int lp_create_mode(int ); int lp_force_create_mode(int ); +int lp_allow_mode(int ); int lp_dir_mode(int ); int lp_force_dir_mode(int ); +int lp_allow_dir_mode(int ); int lp_max_connections(int ); int lp_defaultcase(int ); int lp_minprintspace(int ); diff -u3 -r samba-2.0.4.orig/source/param/loadparm.c samba-2.0.4/source/param/loadparm.c --- samba-2.0.4.orig/source/param/loadparm.c Mon May 17 19:37:43 1999 +++ samba-2.0.4/source/param/loadparm.c Tue Jun 1 11:54:09 1999 @@ -294,8 +294,10 @@ int iMinPrintSpace; int iCreate_mask; int iCreate_force_mode; + int iAllow_mask; int iDir_mask; int iDir_force_mode; + int iAllow_dir_mask; int iMaxConnections; int iDefaultCase; int iPrinting; @@ -389,8 +391,10 @@ 0, /* iMinPrintSpace */ 0744, /* iCreate_mask */ 0000, /* iCreate_force_mode */ + 0000, /* iAllow_mask */ 0755, /* iDir_mask */ 0000, /* iDir_force_mode */ + 0000, /* iAllow_dir_mask */ 0, /* iMaxConnections */ CASE_LOWER, /* iDefaultCase */ DEFAULT_PRINTING, /* iPrinting */ @@ -572,9 +576,13 @@ {"create mask", P_OCTAL, P_LOCAL, &sDefault.iCreate_mask, NULL, NULL, FLAG_GLOBAL|FLAG_SHARE}, {"create mode", P_OCTAL, P_LOCAL, &sDefault.iCreate_mask, NULL, NULL, FLAG_GLOBAL}, {"force create mode",P_OCTAL, P_LOCAL, &sDefault.iCreate_force_mode, NULL, NULL, FLAG_GLOBAL|FLAG_SHARE}, + {"allow mask", P_OCTAL, P_LOCAL, &sDefault.iAllow_mask, NULL, NULL, FLAG_GLOBAL|FLAG_SHARE}, + {"allow mode", P_OCTAL, P_LOCAL, &sDefault.iAllow_mask, NULL, NULL, FLAG_GLOBAL}, {"directory mask", P_OCTAL, P_LOCAL, &sDefault.iDir_mask, NULL, NULL, FLAG_GLOBAL|FLAG_SHARE}, {"directory mode", P_OCTAL, P_LOCAL, &sDefault.iDir_mask, NULL, NULL, FLAG_GLOBAL}, {"force directory mode", P_OCTAL, P_LOCAL, &sDefault.iDir_force_mode, NULL, NULL, FLAG_GLOBAL|FLAG_SHARE}, + {"allow directory mask", P_OCTAL, P_LOCAL, &sDefault.iAllow_dir_mask, NULL, NULL, FLAG_GLOBAL|FLAG_SHARE}, + {"allow directory mode", P_OCTAL, P_LOCAL, &sDefault.iAllow_dir_mask, NULL, NULL, FLAG_GLOBAL}, {"guest only", P_BOOL, P_LOCAL, &sDefault.bGuest_only, NULL, NULL, FLAG_SHARE}, {"only guest", P_BOOL, P_LOCAL, &sDefault.bGuest_only, NULL, NULL, 0}, {"guest ok", P_BOOL, P_LOCAL, &sDefault.bGuest_ok, NULL, NULL, FLAG_BASIC|FLAG_SHARE|FLAG_PRINT}, @@ -1337,8 +1345,10 @@ FN_LOCAL_INTEGER(lp_create_mode,iCreate_mask) FN_LOCAL_INTEGER(lp_force_create_mode,iCreate_force_mode) +FN_LOCAL_INTEGER(lp_allow_mode,iAllow_mask) FN_LOCAL_INTEGER(lp_dir_mode,iDir_mask) FN_LOCAL_INTEGER(lp_force_dir_mode,iDir_force_mode) +FN_LOCAL_INTEGER(lp_allow_dir_mode,iAllow_dir_mask) FN_LOCAL_INTEGER(lp_max_connections,iMaxConnections) FN_LOCAL_INTEGER(lp_defaultcase,iDefaultCase) FN_LOCAL_INTEGER(lp_minprintspace,iMinPrintSpace) @@ -1346,8 +1356,6 @@ FN_LOCAL_INTEGER(lp_oplock_contention_limit,iOplockContentionLimit) FN_LOCAL_CHAR(lp_magicchar,magic_char) - - /* local prototypes */ static int strwicmp( char *psz1, char *psz2 ); diff -u3 -r samba-2.0.4.orig/source/smbd/nttrans.c samba-2.0.4/source/smbd/nttrans.c --- samba-2.0.4.orig/source/smbd/nttrans.c Fri May 14 21:06:39 1999 +++ samba-2.0.4/source/smbd/nttrans.c Tue Jun 1 14:24:55 1999 @@ -2238,6 +2238,28 @@ fsp->fsp_name, (unsigned int)user, (unsigned int)grp, strerror(errno) )); return(UNIXERROR(ERRDOS,ERRnoaccess)); } + + /* + * Recheck the current state of the file, which may have changed. + * (suid/sgid bits, for instance) + */ + + if(fsp->is_directory) { + if(dos_stat(fsp->fsp_name, &sbuf) != 0) { + return(UNIXERROR(ERRDOS,ERRnoaccess)); + } + } else { + + int ret; + + if(fsp->fd_ptr == NULL) + ret = dos_stat(fsp->fsp_name, &sbuf); + else + ret = sys_fstat(fsp->fd_ptr->fd,&sbuf); + + if(ret != 0) + return(UNIXERROR(ERRDOS,ERRnoaccess)); + } } /* @@ -2249,20 +2271,26 @@ free_sec_desc(&psd); /* - * Check to see if we need to change anything. + * Don't mangle unmodified permissions, but enforce limits on modified bits. */ if(fsp->is_directory) { - perms &= lp_dir_mode(SNUM(conn)); - perms |= lp_force_dir_mode(SNUM(conn)); + perms &= lp_dir_mode(SNUM(conn)) | lp_allow_dir_mode(SNUM(conn)) | sbuf.st_mode; + perms |= lp_force_dir_mode(SNUM(conn)) & (sbuf.st_mode ^ perms); } else { - perms &= lp_create_mode(SNUM(conn)); - perms |= lp_force_create_mode(SNUM(conn)); + perms &= lp_create_mode(SNUM(conn)) | lp_allow_mode(SNUM(conn)) | sbuf.st_mode; + perms |= lp_force_create_mode(SNUM(conn)) & (sbuf.st_mode ^ perms); } + + /* + * Preserve special bits. + */ + + perms |= sbuf.st_mode & ~0777; /* * Do we need to chmod ? From matthias at waechter.wol.at Mon Jun 14 17:12:50 1999 From: matthias at waechter.wol.at (=?iso-8859-1?Q?Matthias_W=E4chter?=) Date: Tue Dec 2 03:03:06 2003 Subject: umlauts In-Reply-To: <3765323B.A65C5399@engr.sgi.com> Message-ID: On Tue, 15 Jun 1999, Jeremy Allison wrote: > There's also the problem that umlaut characters will be sent in > MS-Unicode encoding format when sent in DCE/RPC packets. Correct > decoding of this isn't currently implemented in Samba. ah! That may be the (only) problem that my patches produce: Even if a resource can be shared by f.e. "net use x: \\s?rwa\sch?r", it is viewed incorrectly by "net view \\s?rwa" though "net view /domain:dom?in" works perfectly showing s?rwa with the correct umlauts. This problem only occurs under WinNT, not on Win95 or Win98. > I have a plan on how to do this but haven't yet implemented it. I did the patches in March but waited for a solution on the above problem. Well, maybe we will have umlaut support soon? :-) Are there any RPC-NT-Unicode translations available yet? Information on this anywhere? > > BTW: Gurus, which is the correct mailinglist for development discussions > > concerning something like Umlaut Support? > samba-technical is the right mailing list for development issues. ok, let's put it there. Sehr Wus, - Matthias -- Bunt ist das Dasein und granatenstark. Und: Volle Kanne, Hoschis! aus: "Bill und Teds verr?ckte Reise durch die Zeit" ----------------------------------------------------------------------------- From jallison at cthulhu.engr.sgi.com Mon Jun 14 19:06:43 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:06 2003 Subject: FW: patch for safer/saner permissions setting References: <51FBD4A8EFD9D111BA7300A0C927DADB563086@xcgmd008.md.essd.northgrum.com> Message-ID: <376552C3.F5D9CFCB@engr.sgi.com> Cole, Timothy D. wrote: > > I originally sent this to samba-bugs, but didn't see any response... > apologies if this has already hit CVS in some form or another; I can't use > CVS from behind the firewall, and the samba-cvs archives seem to be b0rked > as well. > > --- begin forwarded message --- > > > I've been playing with the permissions setting in 2.0.4 from an NT client, > > and I'm finding that: > > > > 1. most of the time you want to allow the user to set permissions > > broader than the creation mask if they want > > > > 2. existing permission bits always get silently mangled (by the creation > > mask and the forced mode, as well as suid/sgid/sticky bits being > > stripped), even when the user doesn't explicitly change them. This can be > > downright _dangerous_ in some cases, particularly with force mode > > > > The attached patch (against 2.0.4, although it should apply to 2.0.4b > > fine) addresses the first issue by adding "allow mask" and "allow > > directory mask" configuration parameters (defaulting to 0000), which are > > ored with the creation mask when determining what permission bits the user > > can set (so, if she desires, the sysadmin can allow users to set a more > > liberal permissions than allowed by the creation mask alone). The patch > > also allows Samba to preserve any permission bits that the user hasn't > > directly modified. > > Thanks for that patch. This is very close to the ideal semantics, but I'd like to change it a little. Firstly, using the "force mode" but not the "create mask" is confusing (at least to me :-). For that reason I'd like to change it to use 4 new parameters : security mask force security mode and 2 more for directories. These parameters would (if not set in the smb.conf file) be set to the same values as the create mask and force create mode parameters. This allows by default the behavior not to change and also allows an admin to have complete control over the permissions that can be set by a user (and by default they'll be the same as the create restrictions). I also think the idea of retaining the extended security (setuid, sticky etc.) bits is a good one, but I'm not sure how to rationalize this with the current behaviour which prevents any Samba created file from containing any of these bits unless set in the "force mask". What do you think ? Regards, Jeremy Allison, Samba Team. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From davecb at canada.sun.com Mon Jun 14 19:58:13 1999 From: davecb at canada.sun.com (David Collier-Brown) Date: Tue Dec 2 03:03:06 2003 Subject: FW: patch for safer/saner permissions setting References: <51FBD4A8EFD9D111BA7300A0C927DADB563086@xcgmd008.md.essd.northgrum.com> <376552C3.F5D9CFCB@engr.sgi.com> Message-ID: <37655ED5.49D9A7C@canada.sun.com> Jeremy Allison wrote: > I also think the idea of retaining the extended security > (setuid, sticky etc.) bits is a good one, but I'm not sure > how to rationalize this with the current behaviour which > prevents any Samba created file from containing any > of these bits unless set in the "force mask". Logically, I can argue that the special bits should be honored/retained by Samba if the ordinary create mask allows them, and forced into place if the force masks sets them. That's sufficient, and probably necessary (in the adademics' sense of "necessary"). --dave -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | http://java.science.yorku.ca/~davecb Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb@canada.sun.com From jallison at cthulhu.engr.sgi.com Mon Jun 14 20:14:55 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:06 2003 Subject: FW: patch for safer/saner permissions setting References: <51FBD4A8EFD9D111BA7300A0C927DADB563086@xcgmd008.md.essd.northgrum.com> <376552C3.F5D9CFCB@engr.sgi.com> <37655ED5.49D9A7C@canada.sun.com> Message-ID: <376562BF.22C00135@engr.sgi.com> David Collier-Brown wrote: > Logically, I can argue that the special bits > should be honored/retained by Samba if the > ordinary create mask allows them, and forced > into place if the force masks sets them. > > That's sufficient, and probably necessary > (in the adademics' sense of "necessary"). Yeeesssss, sort of, but currently all examples are given without including the special bits, with the result that Samba never creates files with the group setuid bit set (for BSD semantics on directories for example). A counter arguement is that if an admin sets up directory with the BSD inherit group semantics then, as there is no way in the NT permissions dialog to set it then Samba should just leave the special bits alone on a security chane SMB. Jeremy. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From timothy_d_cole at md.northgrum.com Mon Jun 14 20:50:19 1999 From: timothy_d_cole at md.northgrum.com (Cole, Timothy D.) Date: Tue Dec 2 03:03:07 2003 Subject: FW: patch for safer/saner permissions setting Message-ID: <51FBD4A8EFD9D111BA7300A0C927DADB563087@xcgmd008.md.essd.northgrum.com> > Thanks for that patch. This is very close to the ideal > semantics, but I'd like to change it a little. > > Firstly, using the "force mode" but not the "create mask" > is confusing (at least to me :-). > > For that reason I'd like to change it to use 4 new parameters : > > security mask > force security mode > > and 2 more for directories. These parameters would (if not > set in the smb.conf file) be set to the same values as the > create mask and force create mode parameters. > [Cole, Timothy D.] Hrm; yes, security mask is probably a better name.. [Cole, Timothy D.] > This allows by default the behavior not to change and also > allows an admin to have complete control over the permissions > that can be set by a user (and by default they'll be the same > as the create restrictions). > > I also think the idea of retaining the extended security > (setuid, sticky etc.) bits is a good one, but I'm not sure > how to rationalize this with the current behaviour which > prevents any Samba created file from containing any > of these bits unless set in the "force mask". > [Cole, Timothy D.] Any files that have these bits set (if they weren't in the "force mask") either weren't Samba-created to begin with, or their permissions were later deliberately modified from the Unix side, and the current configuration options are really only applicable to file creation. It is broken behavior to force Samba creation restrictions on them after the fact, then, especially without notifying the user. It is OK for Samba to rely on the create mask and force mode parameters to dictate the permissions of a file at creation time, and it is OK for Samba to prevent me from changing a permissions bit on an existing file, but it is NEVER OK for Samba to change a permissions bit that I did not try to change on an existing file. This, of course, applies for the extended bits just as much as it does for the normal bits. (if changing a bit has side-effects for other bits naturally under Samba's host OS, then that is another matter, and Samba's only responsibility is not to defeat that behavior -- note the recheck of permissions after a dos_chown() in my patch which prevents things like a suid bit from being re-applied after a chown) [Cole, Timothy D.] > What do you think ? > > Regards, > > Jeremy Allison, > Samba Team. > > -- > -------------------------------------------------------- > Buying an operating system without source is like buying > a self-assembly Space Shuttle with no instructions. > -------------------------------------------------------- From davecb at canada.sun.com Mon Jun 14 21:04:47 1999 From: davecb at canada.sun.com (David Collier-Brown) Date: Tue Dec 2 03:03:07 2003 Subject: FW: patch for safer/saner permissions setting References: <51FBD4A8EFD9D111BA7300A0C927DADB563086@xcgmd008.md.essd.northgrum.com> <376552C3.F5D9CFCB@engr.sgi.com> <37655ED5.49D9A7C@canada.sun.com> <376562BF.22C00135@engr.sgi.com> Message-ID: <37656E6F.8C94A79B@canada.sun.com> Jeremy Allison wrote: > > David Collier-Brown wrote: > > > Logically, I can argue that the special bits > > should be honored/retained by Samba if the > > ordinary create mask allows them, and forced > > into place if the force masks sets them. > > > > That's sufficient, and probably necessary > > (in the adademics' sense of "necessary"). > > Yeeesssss, sort of, but currently all examples are given > without including the special bits, with the result > that Samba never creates files with the group setuid > bit set (for BSD semantics on directories for example). And we'd be silly to break that! > A counter arguement is that if an admin sets up directory > with the BSD inherit group semantics then, as there is no way > in the NT permissions dialog to set it then Samba should > just leave the special bits alone on a security chane SMB. Ok, off we go on one of my favorite hobby-horses (;-)) It's quite possible, over the period from 2.1 to 2.2, to - start out compatible with 2.0 while adding functionality, - change in a manner which is not intrusive, and - end up with a different behavior. I won't go down the "how it works" alley unless asked, but here's a concrete example of how it **could** be done in Samba. In 2.1, make a visible change: i) add the ability to use the special bits in all masks ii) change the default "permit" mask include all the appropriate extra bits, and the default force mask (as it is now) contain none of them. iii) change the code to warn if a user-set permit mask doesn't include them, AND a file would thereby lose the bits, at log leave 0 (you need a "whoops" bit temporarily to do this). HOWEVER, do NOT turn off the bits until 2.2. During this period: 90% of the users won't ever care 9% will notice, care and fix their masks 1% will complain that the permit mask is broken (:-)) As of 2.2, make another, less visible change i) honor the permit mask and unset the bits ii) On hitting a file with them set, logging the removal at level 0 with a message about what to change in the mask to get the desired behavior. Drop the "whoops" bit. Now: 98% won't care 1% will be pleased you finally fixed the permit mask 1% will ask what happened to the sticky bit (;-)) This is actually more complex than the normal case of "transparent continuous maintenance", as there is a capability that's not fully implemented in 2.1: normally one just can add capabilities in to at that stage. --dave [This is from a talk by Paul Stachour on how the old ARPAnet did continuous software changes in Honeywell NIMs while the net was running, and occasionally backed them out when they didn't work, all without reboots or interruptions] -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | http://java.science.yorku.ca/~davecb Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb@canada.sun.com From timothy_d_cole at md.northgrum.com Mon Jun 14 21:07:07 1999 From: timothy_d_cole at md.northgrum.com (Cole, Timothy D.) Date: Tue Dec 2 03:03:07 2003 Subject: FW: patch for safer/saner permissions setting Message-ID: <51FBD4A8EFD9D111BA7300A0C927DADB563088@xcgmd008.md.essd.northgrum.com> > David Collier-Brown wrote: > > > Logically, I can argue that the special bits > > should be honored/retained by Samba if the > > ordinary create mask allows them, and forced > > into place if the force masks sets them. > > > > That's sufficient, and probably necessary > > (in the adademics' sense of "necessary"). > > Yeeesssss, sort of, but currently all examples are given > without including the special bits, with the result > that Samba never creates files with the group setuid > bit set (for BSD semantics on directories for example). > [Cole, Timothy D.] Actually, I just tried that, and at least under HP-UX, stock 2.0.3 does appear to honor the OS's normal semantics wrt creation of files in sgid directories, even though the create mask would not seem to allow that. Although I haven't tracked down the relevent code yet, I suspect it uses the umask alone to enforce the create mask, and then subsequently just ORs in the force mode with a stat()/chmod(). (which is IMO the right thing to do, as it results in the permissions widening instead of narrowing towards the desired creation permissions, minimizing the possibility for dangerous security races, as well as honoring the OS's own semantics as nearly as possible) [Cole, Timothy D.] > A counter arguement is that if an admin sets up directory > with the BSD inherit group semantics then, as there is no way > in the NT permissions dialog to set it then Samba should > just leave the special bits alone on a security chane SMB. > [Cole, Timothy D.] The best way of looking at it is to consider which of the two behaviors will cause the least damage. I believe that the "safest" behavior is to try as hard as possible to honor the normal behavior of the OS, enforcing Samba's special restrictions only on specific changes made through the "user interface" provided through SMB itself, and never discarding any bits that the OS does not discard. As for those bits that cannot be manipulated via the NT permissions dialog, let sleeping bits lie. [Cole, Timothy D.] > Jeremy. > > -- > -------------------------------------------------------- > Buying an operating system without source is like buying > a self-assembly Space Shuttle with no instructions. > -------------------------------------------------------- From sharpe at ns.aus.com Tue Jun 15 08:07:18 1999 From: sharpe at ns.aus.com (Richard Sharpe) Date: Tue Dec 2 03:03:07 2003 Subject: IPC$ share and access Message-ID: <3.0.5.32.19990615170718.00927950@mail.adelaide.on.net> Hi, I was just having some problems with browsing a Samba server from Win 95, so I fired up Net Mon to see what was going on. When I double click on the System Icon on NN, it would pause for a long while, then came back to me and asked for for a password. If I entered my password (which had a capital as the first letter) I could view the shares on the SMB server. When I looked at the netmon trace, here is what was happening: 1. The first sessionsetup&X was sending my password over in all caps, and Samba was objecting. This gave me the clue to add password level = 8, 2. Then another attempt was made with a different format of the sessionsetup&X, which also failed, as the password was still in all caps, I think. 3. Then I was prompted and I typed in my password, which was sent over verbatim, and all worked OK. Some wierd things going on in Win9x. I will have to fire up Ethereal and see what format sessionsetup&X was being sent ... Regards ------- Richard Sharpe, sharpe@ns.aus.com, NS Computer Software and Services P/L, Samba (Team member www.samba.org), Ethereal (Team member www.zing.org) Co-author, SAMS Teach Yourself Samba in 24 Hours From bmustafa at obl.bilkent.edu.tr Tue Jun 15 08:27:14 1999 From: bmustafa at obl.bilkent.edu.tr (=?iso-8859-9?Q?Mustafa_BA=DEER?=) Date: Tue Dec 2 03:03:07 2003 Subject: Turkish Character Problem with SAMBA Message-ID: Hello, We are Turkish users of Samba. We have problem with Turkish characters with Samba while writing filenames that includes Trukish caharcters on Samba from Windows machines. I prepared a Turkish cahracter set map and include it in charcnv.c. I prepared this map as follows; \xxx\yyy where xxx and yyy are both octal. xxx is the character in MS-DOS Code page 857 and yyy is the character in iso8859-9. My first question is: Is it correct? I also prepared codepage.857. I compiled Samba with may charcnv.c I set character set=iso8859-9 client code page=857 log level=10 #to see if there is sometihn wrong I started samba, and there is noting wrogn in log files. That is, it recognized both iso8859-9 and 857. But I still connot create files which includes Turkish characters on Samba. What else do I have to do? May charcnv.c is as follows #include "includes.h" #define CTRLZ 26 extern int DEBUGLEVEL; static char cvtbuf[1024]; static BOOL mapsinited = 0; static char unix2dos[256]; static char dos2unix[256]; static void initmaps(void) { int k; for (k = 0; k < 256; k++) unix2dos[k] = k; for (k = 0; k < 256; k++) dos2unix[k] = k; mapsinited = True; } static void update_map(char * str) { char *p; for (p = str; *p; p++) { if (p[1]) { unix2dos[(unsigned char)*p] = p[1]; dos2unix[(unsigned char)p[1]] = *p; p++; } } } static void init_iso8859_1(void) { int i; if (!mapsinited) initmaps(); /* Do not map undefined characters to some accidental code */ for (i = 128; i < 256; i++) { unix2dos[i] = CTRLZ; dos2unix[i] = CTRLZ; } /* MSDOS Code Page 850 -> ISO-8859 */ update_map("\240\377\241\255\242\275\243\234\244\317\245\276\246\335\247\365"); update_map("\250\371\251\270\252\246\253\256\254\252\255\360\256\251\257\356"); update_map("\260\370\261\361\262\375\263\374\264\357\265\346\266\364\267\372"); update_map("\270\367\271\373\272\247\273\257\274\254\275\253\276\363\277\250"); update_map("\300\267\301\265\302\266\303\307\304\216\305\217\306\222\307\200"); update_map("\310\324\311\220\312\322\313\323\314\336\315\326\316\327\317\330"); update_map("\320\321\321\245\322\343\323\340\324\342\325\345\326\231\327\236"); update_map("\330\235\331\353\332\351\333\352\334\232\335\355\336\350\337\341"); update_map("\340\205\341\240\342\203\343\306\344\204\345\206\346\221\347\207"); update_map("\350\212\351\202\352\210\353\211\354\215\355\241\356\214\357\213"); update_map("\360\320\361\244\362\225\363\242\364\223\365\344\366\224\367\366"); update_map("\370\233\371\227\372\243\373\226\374\201\375\354\376\347\377\230"); } /* Init for eastern european languages. */ static void init_iso8859_2(void) { int i; if (!mapsinited) initmaps(); /* Do not map undefined characters to some accidental code */ for (i = 128; i < 256; i++) { unix2dos[i] = CTRLZ; dos2unix[i] = CTRLZ; } /* * Tranlation table created by Petr Hubeny * Requires client code page = 852 * and character set = ISO8859-2 in smb.conf */ /* MSDOS Code Page 852 -> ISO-8859-2 */ update_map("\241\244\242\364\243\235\244\317\245\225\246\227\247\365"); update_map("\250\371\251\346\252\270\253\233\254\215\256\246\257\275"); update_map("\261\245\262\362\263\210\264\357\265\226\266\230\267\363"); update_map("\270\367\271\347\272\255\273\234\274\253\275\361\276\247\277\276"); update_map("\300\350\301\265\302\266\303\306\304\216\305\221\306\217\307\200"); update_map("\310\254\311\220\312\250\313\323\314\267\315\326\316\327\317\322"); update_map("\320\321\321\343\322\325\323\340\324\342\325\212\326\231\327\236"); update_map("\330\374\331\336\332\351\333\353\334\232\335\355\336\335\337\341"); update_map("\340\352\341\240\342\203\343\307\344\204\345\222\346\206\347\207"); update_map("\350\237\351\202\352\251\353\211\354\330\355\241\356\214\357\324"); update_map("\360\320\361\344\362\345\363\242\364\223\365\213\366\224\367\366"); update_map("\370\375\371\205\372\243\373\373\374\201\375\354\376\356\377\372"); } /* Init for russian language (iso8859-5) */ /* Added by Max Khon */ static void init_iso8859_5(void) { int i; if (!mapsinited) initmaps(); /* Do not map undefined characters to some accidental code */ for (i = 128; i < 256; i++) { unix2dos[i] = CTRLZ; dos2unix[i] = CTRLZ; } /* MSDOS Code Page 866 -> ISO8859-5 */ update_map("\260\200\261\201\262\202\263\203\264\204\265\205\266\206\267\207"); update_map("\270\210\271\211\272\212\273\213\274\214\275\215\276\216\277\217"); update_map("\300\220\301\221\302\222\303\223\304\224\305\225\306\226\307\227"); update_map("\310\230\311\231\312\232\313\233\314\234\315\235\316\236\317\237"); update_map("\320\240\321\241\322\242\323\243\324\244\325\245\326\246\327\247"); update_map("\330\250\331\251\332\252\333\253\334\254\335\255\336\256\337\257"); update_map("\340\340\341\341\342\342\343\343\344\344\345\345\346\346\347\347"); update_map("\350\350\351\351\352\352\353\353\354\354\355\355\356\356\357\357"); update_map("\241\360\361\361\244\362\364\363\247\364\367\365\256\366\376\367"); update_map("\360\374\240\377"); } /* Init for russian language (koi8) */ static void init_koi8_r(void) { if (!mapsinited) initmaps(); /* There aren't undefined characters between 128 and 255 */ /* MSDOS Code Page 866 -> KOI8-R */ update_map("\200\304\201\263\202\332\203\277\204\300\205\331\206\303\207\264"); update_map("\210\302\211\301\212\305\213\337\214\334\215\333\216\335\217\336"); update_map("\220\260\221\261\222\262\223\364\224\376\225\371\226\373\227\367"); update_map("\230\363\231\362\232\377\233\365\234\370\235\375\236\372\237\366"); update_map("\240\315\241\272\242\325\243\361\244\326\245\311\246\270\247\267"); update_map("\250\273\251\324\252\323\253\310\254\276\255\275\256\274\257\306"); update_map("\260\307\261\314\262\265\263\360\264\266\265\271\266\321\267\322"); update_map("\270\313\271\317\272\320\273\312\274\330\275\327\276\316\277\374"); update_map("\300\356\301\240\302\241\303\346\304\244\305\245\306\344\307\243"); update_map("\310\345\311\250\312\251\313\252\314\253\315\254\316\255\317\256"); update_map("\320\257\321\357\322\340\323\341\324\342\325\343\326\246\327\242"); update_map("\330\354\331\353\332\247\333\350\334\355\335\351\336\347\337\352"); update_map("\340\236\341\200\342\201\343\226\344\204\345\205\346\224\347\203"); update_map("\350\225\351\210\352\211\353\212\354\213\355\214\356\215\357\216"); update_map("\360\217\361\237\362\220\363\221\364\222\365\223\366\206\367\202"); update_map("\370\234\371\233\372\207\373\230\374\235\375\231\376\227\377\232"); } /* Init for Turkish language. */ static void init_iso8859_9(void) { int i; if (!mapsinited) initmaps(); /* Do not map undefined characters to some accidental code */ for (i = 128; i < 256; i++) { unix2dos[i] = CTRLZ; dos2unix[i] = CTRLZ; } /* * Tranlation table created by Mustafa Baser * Requires client code page = 857 * and character set = ISO8859-9 in smb.conf */ /* MSDOS Code Page 857 -> ISO-8859-9 */ update_map("\246\320\247\360\236\336\237\376\230\335\215\375"); update_map("\232\334\201\374\231\326\224\366\200\307\207\347"); } /* * Convert unix to dos */ char *unix2dos_format(char *str,BOOL overwrite) { char *p; char *dp; if (!mapsinited) initmaps(); if (overwrite) { for (p = str; *p; p++) *p = unix2dos[(unsigned char)*p]; return str; } else { for (p = str, dp = cvtbuf; *p; p++,dp++) *dp = unix2dos[(unsigned char)*p]; *dp = 0; return cvtbuf; } } /* * Convert dos to unix */ char *dos2unix_format(char *str, BOOL overwrite) { char *p; char *dp; if (!mapsinited) initmaps(); if (overwrite) { for (p = str; *p; p++) *p = dos2unix[(unsigned char)*p]; return str; } else { for (p = str, dp = cvtbuf; *p; p++,dp++) *dp = dos2unix[(unsigned char)*p]; *dp = 0; return cvtbuf; } } /* * Interpret character set. */ void interpret_character_set(char *str) { if (strequal (str, "iso8859-1")) { init_iso8859_1(); } else if (strequal (str, "iso8859-2")) { init_iso8859_2(); } else if (strequal (str, "iso8859-5")) { init_iso8859_5(); } else if (strequal (str, "koi8-r")) { init_koi8_r(); } else if (strequal (str, "iso8859-9")) { init_iso8859_9(); } else { DEBUG(0,("unrecognized character set %s\n", str)); } } From rrln at esegi.es Tue Jun 15 10:51:54 1999 From: rrln at esegi.es (Roberto Lopez) Date: Tue Dec 2 03:03:07 2003 Subject: Mapping drive error Message-ID: <002701beb71d$1530b200$9412a8c0@pcrrln.esegi.es> Hi I am a newbie so forgive me if this quuestion has been already answered. I have a Linux box behind a firewall. I have compiled, installed and configured a Samba server (2.0.4) in the Linux box (redHat 5.0). Basically I have an out-of-the-box configuration: # Global parameters workgroup = SGI Netbios name = prueba server string = Servidor Prueba security = SHARE log file = /root/smb.log max log size = 1000000 read prediction = Yes read size = 8192 socket options = TCP_NODELAY lm announce = True invalid users = root hosts allow = 192.168.18.148 queuepause command = enable %p remote announce = 192.168.18.255/SGI [todo] path = /usr/local read only = Yes guest ok = Yes The firewall allows traffic through port 139 and have a NAT rule for the server. Well, I am able to connect to the Samba server using smbclient from other Samba server, but when I try to map a network drive in a W95, it produces the followin message: "The network is busy" (or something like this, because its a Spanish translated edition). Well, I want to know what this error message means. Any clue will help. Thanks From rrln at esegi.es Tue Jun 15 13:43:01 1999 From: rrln at esegi.es (Roberto Lopez) Date: Tue Dec 2 03:03:07 2003 Subject: Mapping error again... Message-ID: <001d01beb734$fcb42780$9412a8c0@pcrrln.esegi.es> Oh, all of you are right. That was the first thing I tried. The point is that I forgot one little thing in my previos message. I use the lmhosts file for name resolution. As long as I know, port 137 and 138 are used by precisely for name resolution. More info: I am able to connect without a problem when I replicate the configuration at the office, but I am not able to reproduce the message. I expect it was a client problem, i.e, W95. I look around to see some info related to this extrange message, but without any luck. I would spend some time reading RFC 1001 and 1002, setting log level to 100 and burning my eyes on them but my boss has other plans for me. But I promise to do so as soon as I can. So maybe you could say something more about this issue.... Thanks a lot. It feels good to know there are a lot of people out there who can waste five minutes for helping someone like me. Thaks a lot indeed. From crh at nts.umn.edu Tue Jun 15 14:58:16 1999 From: crh at nts.umn.edu (Christopher R. Hertel) Date: Tue Dec 2 03:03:07 2003 Subject: Mapping drive error In-Reply-To: <002701beb71d$1530b200$9412a8c0@pcrrln.esegi.es> from "Roberto Lopez" at Jun 15, 99 08:52:03 pm Message-ID: <199906151458.JAA15724@unet.unet.umn.edu> > The firewall allows traffic through port 139 and have a NAT rule for the > server. You might want to map UDP/137 and possibly UDP/138 through the NAT as well. It *shouldn't* matter, but there may be NetBIOS name resolution problems without these. Let me know if this works. I've had people here at the U complain of similar symptoms. They were trying to run smbd without running nmbd. I've asked them to run nmbd and let me know but I haven't heard back. Do you have any Windows boxes inside the firewall? Can they mount the shares? Chris -)----- -- -- I have a shoehorn, the kind with teeth. -- --- Christopher R. Hertel -)----- University of Minnesota crh@nts.umn.edu Networking and Telecommunications Services From crh at nts.umn.edu Tue Jun 15 18:11:55 1999 From: crh at nts.umn.edu (Christopher R. Hertel) Date: Tue Dec 2 03:03:07 2003 Subject: Mapping drive error In-Reply-To: <00a101beb742$5e28a880$9412a8c0@pcrrln.esegi.es> from "Roberto Lopez" at Jun 15, 99 05:18:48 pm Message-ID: <199906151811.NAA13334@unet.unet.umn.edu> Roberto, > I hope that addresing this mail directly to you is not an inconvenience. If > so, please forgive me. Not a problem, though you might get better results from the list as a whole. > Well, I mapped both ports. As a matter of fact, I allowed any kind of > traffic between the W95 box and the samba server. And, as I said in a latter > posting, I use the lmhosts file for name resolution. So I am force to > discard name resolution issues. LMHosts is *supposed* to work on its own, but I'm not sure that it does in all cases. Samba is fine without the name service, but I have a department that is trying to run Samba without running nmbd and they are also reporting that some systems cannot connect. It is *possible* that some Windows code needs to talk to port UDP/137 (or UDP/138-though I doubt it) in order to complete a connection. Anyway, I want to know if this is a possibility before I try digging any further. > Latter I allowed only TCP/139. The packet trace is a bit odd, but since the > smblient (on another samba server in the same subnet as the W95 box) was > able to connect without a problem, I am inclined to think that it was some > kind of misunderstanding between W95 and Samba. I don't understand. Did opening your firewall fix the problem? > It is the strange message W95 pop-ups what it's bothering me. I would like > to know what it does means. Tell me once again what the message is. > Well, when I know what is happening I would make a ***huge*** report to the > lost. That would be great! > Thanks for your time. > > Bets regards > > > Roberto Lopez > rrln@esegi.es Chris -)----- -- -- I have a shoehorn, the kind with teeth. -- --- Christopher R. Hertel -)----- University of Minnesota crh@nts.umn.edu Networking and Telecommunications Services From Volker.Lendecke at SerNet.DE Wed Jun 16 04:00:59 1999 From: Volker.Lendecke at SerNet.DE (Volker.Lendecke@SerNet.DE) Date: Tue Dec 2 03:03:07 2003 Subject: Multi-Workgroup DMB ? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hi! Please excuse this user-only question here... I remember that Luke was once playing around with multi workgroup browsing in Samba. Luke, have you finished that? And if yes, how do I configure Samba as a multi-wg DMB? Volker -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBN2chdT/9BWnmOc5FAQGf9QP9EUEc2nrjlhLoSIJZ4m9mYy0+MZHiBWuD YkLWoDuthyc0slBYDaZXLqDYEmsRHv6vlT9yYzDqZKRm1OHGRjVe8eVC4fcrBHaf XfxnrDF3EtOawMSpN39FjWD7E5DvWmIaxzSGGwGTw/eq/5Gwg7SWmkXnqikcTRoj AmOfPYY0j/g= =J70j -----END PGP SIGNATURE----- From Tim.Potter at anu.edu.au Wed Jun 16 04:55:47 1999 From: Tim.Potter at anu.edu.au (Tim Potter) Date: Tue Dec 2 03:03:07 2003 Subject: Problem with rpcclient svcenum command Message-ID: <14183.11859.601489.974340@acronym.anu.edu.au> I get the following error when trying to list services on a remote machine. smb: \> svcenum svcenum SVC_ENUM_SVCS_STATUS: ERRDOS - ERRmoredata (There is more data to be returned.) Memory allocation error: failed to expand to -916717568 bytes svc_io_r_enum_svcs_status: Realloc failed Is there any way to start/stop services using rpcclient? That would be pretty neat. Tim. -- Tim Potter, System Admin/Programmer, Head Bee Guy Advanced Computational Systems CRC, RSISE Bldg Australian National University, Canberra 0200, AUSTRALIA Ph: +61 2 62798813 Fax: +61 2 62798602 From effugas at best.com Wed Jun 16 11:53:50 1999 From: effugas at best.com (Dan Kaminsky) Date: Tue Dec 2 03:03:07 2003 Subject: DCE/DFS gone? Message-ID: <199906161153.EAA04805@shell3.ba.best.com> I didn't even know they were implemented, but there I saw in the examples directory a configuration for DFS! So, I found in the ./configure file --with-dfs and recompiled. passdb/pass_check.c:173: dce/dce_error.h: No such file or directory passdb/pass_check.c:174: dce/sec_login.h: No such file or directory Yup, it ain't there. How sad; I really wanted to play with this. (For those who don't know, DFS lets you link an arbitrary number of machines into a single server's namespace.) Yours Truly, Dan Kaminsky DoxPara Research http://doxpara.netpedia.net From borsenkow.msk at sni.de Tue Jun 15 13:33:45 1999 From: borsenkow.msk at sni.de (Andrej Borsenkow) Date: Tue Dec 2 03:03:07 2003 Subject: Autoreconnect from WinNT problem RE: FW: 2.0.4b: unacceptable long browsing times from Windows2000 Beta3 In-Reply-To: <37610754.EF4F928D@cse.unsw.edu.au> Message-ID: <000201beb733$b112b180$21c9ca95@mow.siemens.ru> > > Can you try the attached patch against 2.0.4b (which is also a bit of > a tidy-up > of the share enumeration code, hence its size). > I won't claim, that it has something to do with this patch, but now I am connected as nobody after WinNT4.0SP5 startup for all shares. If I kill smbd (e.g. using SWAT) and connect again, I am connected as myself. The NT use is different from Wnix user, and I have user mapping from NT to Unix if it matters. Anybody have seen it? What info is needed? regards /andrej From lkcl at switchboard.net Wed Jun 16 17:32:53 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:07 2003 Subject: Multi-Workgroup DMB ? In-Reply-To: Message-ID: that version, 1.9.17p10-multi-wg.tar.gz was never merged back into the main cvs repository. On Wed, 16 Jun 1999 Volker.Lendecke@SerNet.DE wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > Hi! > > Please excuse this user-only question here... I remember that Luke was > once playing around with multi workgroup browsing in Samba. Luke, have > you finished that? And if yes, how do I configure Samba as a multi-wg > DMB? > > Volker > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3i > Charset: noconv > > iQCVAwUBN2chdT/9BWnmOc5FAQGf9QP9EUEc2nrjlhLoSIJZ4m9mYy0+MZHiBWuD > YkLWoDuthyc0slBYDaZXLqDYEmsRHv6vlT9yYzDqZKRm1OHGRjVe8eVC4fcrBHaf > XfxnrDF3EtOawMSpN39FjWD7E5DvWmIaxzSGGwGTw/eq/5Gwg7SWmkXnqikcTRoj > AmOfPYY0j/g= > =J70j > -----END PGP SIGNATURE----- > Luke Kenneth Casson Leighton Samba and Network Development Samba Web site ===================================================================== Luke Kenneth Casson Leighton | Direct Dial : (678) 443-6183 Systems Engineer / ISS XForce Team | ISS Front Desk: (678) 443-6000 Internet Security Systems, Inc. | ISS Fax : (678) 443-6477 http://www.iss.net/ *Adaptive Network Security for the Enterprise* ISS Connect - International User Conference - May '99 ===================================================================== From lkcl at switchboard.net Wed Jun 16 17:33:48 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:07 2003 Subject: Problem with rpcclient svcenum command In-Reply-To: <14183.11859.601489.974340@acronym.anu.edu.au> Message-ID: On Wed, 16 Jun 1999, Tim Potter wrote: > I get the following error when trying to list services on a remote > machine. > > smb: \> svcenum > svcenum > > SVC_ENUM_SVCS_STATUS: ERRDOS - ERRmoredata (There is more data to be returned.) > Memory allocation error: failed to expand to -916717568 bytes > svc_io_r_enum_svcs_status: Realloc failed please send me a netmon trace from nt to nt. > Is there any way to start/stop services using rpcclient? That would > be pretty neat. ? not yet. anyone want to look at this From lkcl at switchboard.net Wed Jun 16 18:14:38 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:07 2003 Subject: DCE/DFS gone? In-Reply-To: <199906161153.EAA04805@shell3.ba.best.com> Message-ID: dan, check 1.9.18 source and also look for the dce_error.h file on your OS. On Wed, 16 Jun 1999, Dan Kaminsky wrote: > I didn't even know they were implemented, but there I saw in the examples > directory a configuration for DFS! > > So, I found in the ./configure file --with-dfs and recompiled. > > passdb/pass_check.c:173: dce/dce_error.h: No such file or directory > passdb/pass_check.c:174: dce/sec_login.h: No such file or directory > > Yup, it ain't there. How sad; I really wanted to play with this. > > (For those who don't know, DFS lets you link an arbitrary number of > machines into a single server's namespace.) > > Yours Truly, > > Dan Kaminsky > DoxPara Research > http://doxpara.netpedia.net > > Luke Kenneth Casson Leighton Samba and Network Development Samba Web site ===================================================================== Luke Kenneth Casson Leighton | Direct Dial : (678) 443-6183 Systems Engineer / ISS XForce Team | ISS Front Desk: (678) 443-6000 Internet Security Systems, Inc. | ISS Fax : (678) 443-6477 http://www.iss.net/ *Adaptive Network Security for the Enterprise* ISS Connect - International User Conference - May '99 ===================================================================== From Jason.Haar at trimble.co.nz Wed Jun 16 21:03:18 1999 From: Jason.Haar at trimble.co.nz (Jason Haar) Date: Tue Dec 2 03:03:07 2003 Subject: Multi-Workgroup DMB ? In-Reply-To: ; from Luke Kenneth Casson Leighton on Thu, Jun 17, 1999 at 03:35:46AM +1000 References: Message-ID: <19990617090318.B22392@trimble.co.nz> On Thu, Jun 17, 1999 at 03:35:46AM +1000, Luke Kenneth Casson Leighton wrote: > that version, 1.9.17p10-multi-wg.tar.gz was never merged back into the > main cvs repository. Does this lack of multi-domain support explain the security hole in Samba where a user with the same usercode in another NT trusted domain can access the equivalent local domain account under Samba? I've got that problem here... -- Cheers Jason Haar Unix/Network Specialist, Trimble NZ Phone: +64 3 3391 377 Fax: +64 3 3391 417 From lkcl at switchboard.net Wed Jun 16 21:11:12 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:07 2003 Subject: Multi-Workgroup DMB ? In-Reply-To: <19990617090318.B22392@trimble.co.nz> Message-ID: On Thu, 17 Jun 1999, Jason Haar wrote: > On Thu, Jun 17, 1999 at 03:35:46AM +1000, Luke Kenneth Casson Leighton wrote: > > that version, 1.9.17p10-multi-wg.tar.gz was never merged back into the > > main cvs repository. > > Does this lack of multi-domain support explain the security hole in Samba > where a user with the same usercode in another NT trusted domain can access > the equivalent local domain account under Samba? no. From Tim.Potter at anu.edu.au Thu Jun 17 00:49:47 1999 From: Tim.Potter at anu.edu.au (Tim Potter) Date: Tue Dec 2 03:03:07 2003 Subject: Problem with rpcclient svcenum command In-Reply-To: References: <14183.11859.601489.974340@acronym.anu.edu.au> Message-ID: <14184.17963.704612.896135@acronym.anu.edu.au> Luke Kenneth Casson Leighton writes: > > I get the following error when trying to list services on a remote > > machine. > > > > smb: \> svcenum > > svcenum > > > > SVC_ENUM_SVCS_STATUS: ERRDOS - ERRmoredata (There is more data to > > be returned.) > > Memory allocation error: failed to expand to -916717568 bytes > > svc_io_r_enum_svcs_status: Realloc failed > > please send me a netmon trace from nt to nt. Err, is netmon a UNIX program or an NT one? > > Is there any way to start/stop services using rpcclient? That would > > be pretty neat. > ? > not yet. anyone want to look at this I'd be keen if you could give me a few tips to get started. Tim. -- Tim Potter, System Admin/Programmer, Head Bee Guy Advanced Computational Systems CRC, RSISE Bldg Australian National University, Canberra 0200, AUSTRALIA Ph: +61 2 62798813 Fax: +61 2 62798602 From njsain at ozarks.edu Thu Jun 17 03:45:31 1999 From: njsain at ozarks.edu (Nathan j. Sain) Date: Tue Dec 2 03:03:07 2003 Subject: LDAP schema Message-ID: Hello, I'm currently trying to intagrate samba with ldap, but am having trouble finding the samba schema defs. I did find a schema for sambaAccount, but it seems there should be more objects than just sambaAccount could some one please point me to a document or pass on any information the subject. Thanks, Nathan Sain From mkoelle at gmx.de Thu Jun 17 06:10:43 1999 From: mkoelle at gmx.de (Markus Koelle) Date: Tue Dec 2 03:03:07 2003 Subject: Umlaut-Problem mit 2.1pre-alpha-1999-06-16 ? Message-ID: <199906170610.IAA12897@toplink4.toplink.net> Has 2.1-Pre-Alpha-Code an umlaut-problem ? My server-based profiles (with german NT4-Workstation SP4) are broken because of this Umlaut problem . Any ideas ? Thanks in advance Markus K?lle From majid at bol.sharif.ac.ir Thu Jun 17 06:28:35 1999 From: majid at bol.sharif.ac.ir (Majid Tajamolian) Date: Tue Dec 2 03:03:07 2003 Subject: need undelete function (Jeremy, what is your idea?) Message-ID: Hi there: > ps: my little suggestion: if we add some parameters at smb.conf like > protected dir = /home/share, /home/user1 ; > trashcan dir = /smbtrash ; It seems that implementation of such parameter has some difficulties and eventuates reduction on performance (e.g. handling "protected dir"s and "trash dir" on the different devices like /dev/hda1 & /dev/hdb1). I suggest a service specific parameter in smb.conf like the followings: remove utility = /etc/scripts/saferm The benefits with such policy are: 1. The implementation in SAMBA code is much easier. 2. The undelete policy is fully under control of administrator in a per service or global manner. 3. The administrator can turns off it for performance critical services. I am a subscriber of both lists, and have seen a lot of asks for this capability as yet. SAMBA team, What is your idea? -- Cheers, M. Tajamolian Jun 17 From Tim.Potter at anu.edu.au Thu Jun 17 07:54:52 1999 From: Tim.Potter at anu.edu.au (Tim Potter) Date: Tue Dec 2 03:03:07 2003 Subject: need undelete function (Jeremy, what is your idea?) In-Reply-To: References: Message-ID: <14184.43468.672682.685255@acronym.anu.edu.au> Majid Tajamolian writes: > > ps: my little suggestion: if we add some parameters at smb.conf like > > protected dir = /home/share, /home/user1 ; > > trashcan dir = /smbtrash ; > > It seems that implementation of such parameter has some difficulties and > eventuates reduction on performance (e.g. handling "protected dir"s and > "trash dir" on the different devices like /dev/hda1 & /dev/hdb1). > I suggest a service specific parameter in smb.conf like the followings: > > remove utility = /etc/scripts/saferm It seems to me that a lot of these "do X when Y happens" improvements could be handled with some sort of scripting vfs module. It shouldn't be too hard to write, although there is currently no process for defining new entries in smb.conf. Tim. -- Tim Potter, System Admin/Programmer, Head Bee Guy Advanced Computational Systems CRC, RSISE Bldg Australian National University, Canberra 0200, AUSTRALIA Ph: +61 2 62798813 Fax: +61 2 62798602 From dkrovich at wvu.edu Thu Jun 17 06:59:12 1999 From: dkrovich at wvu.edu (David Krovich) Date: Tue Dec 2 03:03:07 2003 Subject: smbpasswd password changing In-Reply-To: <199906101136.NAA15398@ripper.informatik.uni-ulm.de> Message-ID: The passwords I'm trying are shorter than 8 characters... I've pretty much hit a brick wall with this problem, I can't get smbpasswd to work at all with non-root users. :( ----------------------------------------- David Krovich West Virginia University Manager/Information Systems Computer Science & Electrical Engineering ----------------------------------------- On Thu, 10 Jun 1999 lists@ripper.informatik.uni-ulm.de wrote: > > Running Samba 2.0.4b on Solaris 2.5.1 > > > > I can't get smbpasswd to change a password as a normal user. > > (I've allowed 127. in the hosts allow parameter in smb.conf) > > On Solaris smbpasswd uses getpass(3C) to get the old/new passwords from the > user. getpass is limited to return up to PASS_MAX (8) characters on Solaris. > If your password is longer than 8 characters smbpasswd will fail. Try > patching smbpasswd to use getpassphrase(3C) (which returns up to 255 > characters which might give a problem with too long passwords). > > Rainer > From Piet.Ruyssinck at rug.ac.be Thu Jun 17 12:15:57 1999 From: Piet.Ruyssinck at rug.ac.be (Piet Ruyssinck) Date: Tue Dec 2 03:03:07 2003 Subject: I need extra value for "map to guest" Message-ID: <19990617141557.G19323@callisto.rug.ac.be> Hello, I want to avoid having to put all my samba accounts in my /etc/passwd as well as in my smbpasswd file or LDAP server. Users who are authenticated successfully but who are not in /etc/passwd should be mapped to guest. I tried to achieve this with the "map to guest" directive but didn't succeed. This table illustrates the behaviour for the existing values for "map to guest" and the behaviour that I need. authentication user in successful ? /etc/passwd ? map to guest = Never 0 0 rejected 0 1 rejected 1 0 rejected 1 1 personalized login map to guest = Bad User 0 0 guest login 0 1 rejected 1 0 personalized login 1 1 personalized login map to guest = Bad Password 0 0 guest login 0 1 guest login 1 0 rejected 1 1 personalized login What I need : 0 0 rejected 0 1 rejected 1 0 guest login 1 1 personalized login Any idees on how I can get the desired behaviour ? -- -------------------------------------------------------- Piet RUYSSINCK Piet.Ruyssinck@rug.ac.be Unix Systeem Administratie +32 9 264 4733 ACADEMISCH REKENCENTRUM (ARC) Universiteit Gent (RUG) Krijgslaan 281, gebouw S9, bureel 4 9000 Gent, Belgie From cartegw at Eng.Auburn.EDU Thu Jun 17 13:07:55 1999 From: cartegw at Eng.Auburn.EDU (Gerald W. Carter) Date: Tue Dec 2 03:03:07 2003 Subject: Problem with rpcclient svcenum command References: <14183.11859.601489.974340@acronym.anu.edu.au> <14184.17963.704612.896135@acronym.anu.edu.au> Message-ID: <3768F32B.8F24FBE5@eng.auburn.edu> Tim Potter wrote: > > Err, is netmon a UNIX program or an NT one? Microsoft Network Monitor (aka netmon for short). Packet sniffer that does a decent job of decoding some of the MS RPC packets. You can also translate a raw dump from tcpdum-smb to netmon's CAP format. Q3.2 of the Samba NT Domain FAQ has some more information on it. Cheers, jerry ________________________________________________________________________ Gerald ( Jerry ) Carter Engineering Network Services Auburn University jerry@eng.auburn.edu http://www.eng.auburn.edu/users/cartegw "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" ( 1979 ) From abakun at reac.com Thu Jun 17 14:17:07 1999 From: abakun at reac.com (Andy Bakun) Date: Tue Dec 2 03:03:07 2003 Subject: VFS stuff (was Re: need undelete function) References: <14184.43468.672682.685255@acronym.anu.edu.au> Message-ID: <37690363.CB55CDBE@reac.com> I am in total agreement on the scripting VFS module. I've been getting requests to implement a bunch of things similar to my 'close command' patch (http://www.reac.com/samba/samba-closecmd.README), but I'm holding out until the VFS layer that was talked about a few months ago goes gold, because this is a more 'correct' way to do it, in my mind. I'll use this post as a sounding board for some of my ideas. :) I havn't heard much about the VFS layer in a while; is it already in the 2.1 series? Did the developer give up on it? Who was working on it anyway? I'd be willing to implement it if I wasn't duplicating work. Tim, your post seems to indicate that VFS stuff is already written -- am I completely out of the loop? Is there documentation for what's already written? I'd think that the VFS layer can be bound on a per-share basis, thusly: [share] path = /whatever comment = my share vfs link against = /usr/local/samba/lib/my-samba-vfs-layer.so A 'execute script' shared lib could be provided for with the samba distribution. In terms of giving the bound vfs layer configuration parameters, the conf file parsing code could be modified to take things of the form: vfs link against = /path/to/so { vfs option one = x vfs option two = x } I believe this would be easy to implement because the conf file parsing code could just skip over, and not process, things in braces; keeping the things in braces as plain text to pass to the so's init routine. If no vfs link against parameter is specified, just dump whatever is in braces. That would be the easy method. The hard method would be to have all the parameters specified to the share available to the VFS also. Unfortunately, the conf file code ignores parameters it doesn't recognize, so those would have to kept around, taking up memory and such, and which makes parameter name typo hard to detect. Andy. Tim Potter wrote: > Majid Tajamolian writes: > > > > ps: my little suggestion: if we add some parameters at smb.conf like > > > protected dir = /home/share, /home/user1 ; > > > trashcan dir = /smbtrash ; > > > > It seems that implementation of such parameter has some difficulties and > > eventuates reduction on performance (e.g. handling "protected dir"s and > > "trash dir" on the different devices like /dev/hda1 & /dev/hdb1). > > I suggest a service specific parameter in smb.conf like the followings: > > > > remove utility = /etc/scripts/saferm > > It seems to me that a lot of these "do X when Y happens" improvements > could be handled with some sort of scripting vfs module. It shouldn't > be too hard to write, although there is currently no process for defining > new entries in smb.conf. > > Tim. > > -- > Tim Potter, System Admin/Programmer, Head Bee Guy > Advanced Computational Systems CRC, RSISE Bldg Australian National University, > Canberra 0200, AUSTRALIA Ph: +61 2 62798813 Fax: +61 2 62798602 From lkcl at switchboard.net Thu Jun 17 16:50:39 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:07 2003 Subject: Problem with rpcclient svcenum command In-Reply-To: <14184.17963.704612.896135@acronym.anu.edu.au> Message-ID: take a netmon trace. stare at it. take a look at MSDN API (in this case *Service* functions, e.g OpenSCManager). note the similarity between data over-the-wire and the MSDN function parameters. look in include/rpc_xxxx.h (in this case, rpc_svcctl.h). work from a similar example. cut/paste code in rpc_parse/prs_svcctl.c. cut/paste code in rpc_client/cli_svcctl.c. cut/paste code in rpcclient/cmd_svcctl.c, rpcclient/rpcclient.c and rpcclient/display.c. compile. fix. send patch. smile. On Thu, 17 Jun 1999, Tim Potter wrote: > Luke Kenneth Casson Leighton writes: > > > > I get the following error when trying to list services on a remote > > > machine. > > > > > > smb: \> svcenum > > > svcenum > > > > > > SVC_ENUM_SVCS_STATUS: ERRDOS - ERRmoredata (There is more data to > > > be returned.) > > > Memory allocation error: failed to expand to -916717568 bytes > > > svc_io_r_enum_svcs_status: Realloc failed > > > > please send me a netmon trace from nt to nt. > > Err, is netmon a UNIX program or an NT one? > > > > Is there any way to start/stop services using rpcclient? That would > > > be pretty neat. > > ? > > not yet. anyone want to look at this > > I'd be keen if you could give me a few tips to get started. > > > Tim. > > -- > Tim Potter, System Admin/Programmer, Head Bee Guy > Advanced Computational Systems CRC, RSISE Bldg Australian National University, > Canberra 0200, AUSTRALIA Ph: +61 2 62798813 Fax: +61 2 62798602 > Luke Kenneth Casson Leighton Samba and Network Development Samba Web site ===================================================================== Luke Kenneth Casson Leighton | Direct Dial : (678) 443-6183 Systems Engineer / ISS XForce Team | ISS Front Desk: (678) 443-6000 Internet Security Systems, Inc. | ISS Fax : (678) 443-6477 http://www.iss.net/ *Adaptive Network Security for the Enterprise* ISS Connect - International User Conference - May '99 ===================================================================== From beastvol at westmont.edu Thu Jun 17 17:17:58 1999 From: beastvol at westmont.edu (Benjamin Eastvold) Date: Tue Dec 2 03:03:07 2003 Subject: samba doesn't start Message-ID: We have two IBM RS-6000 machines sharing files for our campus library. They are both running AIX v.4.2.1. An older version of samba was already running on them, but we decided to upgrade for security reasons. They both now have the latest version (2.0.4b) installed on them. After the installation, one of them ran fine. The other computer worked correctly for a little while, but then samba decided not to work for some unknown reason. Checking the smbstatus command we got the error message: "ERROR: failed to initialise share modes! Can't initialise shared memory - exiting" We tried killing the smbd and nmbd daemons and restarting them, but it still would not work. Now, after having run fine for a few days, our other server is giving us the same problems. Did we install the program wrong, or is this a bug of some sort? It is very important that we get these computers up as soon as possible. Any help would be greatly appreciated. Thanks very much. Ben Eastvold From brian at bstc.net Thu Jun 17 21:01:21 1999 From: brian at bstc.net (brian@bstc.net) Date: Tue Dec 2 03:03:07 2003 Subject: [Fwd: HELP] Message-ID: <37696221.F78D9038@bstc.net> Please cc this one, I am sure he is not on the list LTtop wrote: > > Sorry fo my English, > I'm using samba 2.0.3 with glibc-2.0.7pre6 on Linux 2.2.6, my problem is > > that my client > (win98) doesn't lock records > and doesn't see when the server locks record. I obtain this with a > cobol application that works > fine and that shares file locking only the record. > I use, in smb.conf, the default configuration. > > HELP ME !! -- ----------------------------------------------------------------- Brian Roberson # Samba Team www.samba.org BrainStorm Technologies # OLUG Founder www.olug.org Linux Solution Provider # FSF programer www.fsf.org 1-800-598-6732 # Linux Lover www.linux.org http://www.bstc.net/ # Unix Guru www.ugu.com From brian at bstc.net Thu Jun 17 21:06:14 1999 From: brian at bstc.net (brian@bstc.net) Date: Tue Dec 2 03:03:07 2003 Subject: [Fwd: HELP] References: <37696221.F78D9038@bstc.net> Message-ID: <37696346.559AAFFA@bstc.net> btw.. I guees You would need this: email: Lttop@hotmail.com --sorry brian@bstc.net wrote: > > Please cc this one, I am sure he is not on the list > > LTtop wrote: > > > > Sorry fo my English, > > I'm using samba 2.0.3 with glibc-2.0.7pre6 on Linux 2.2.6, my problem is > > > > that my client > > (win98) doesn't lock records > > and doesn't see when the server locks record. I obtain this with a > > cobol application that works > > fine and that shares file locking only the record. > > I use, in smb.conf, the default configuration. > > > > HELP ME !! > > -- > ----------------------------------------------------------------- > Brian Roberson # Samba Team www.samba.org > BrainStorm Technologies # OLUG Founder www.olug.org > Linux Solution Provider # FSF programer www.fsf.org > 1-800-598-6732 # Linux Lover www.linux.org > http://www.bstc.net/ # Unix Guru www.ugu.com -- ----------------------------------------------------------------- Brian Roberson # Samba Team www.samba.org BrainStorm Technologies # OLUG Founder www.olug.org Linux Solution Provider # FSF programer www.fsf.org 1-800-598-6732 # Linux Lover www.linux.org http://www.bstc.net/ # Unix Guru www.ugu.com From timothy_d_cole at md.northgrum.com Fri Jun 18 16:29:00 1999 From: timothy_d_cole at md.northgrum.com (Cole, Timothy D.) Date: Tue Dec 2 03:03:07 2003 Subject: more thoughts on Samba permissions manipulation Message-ID: <51FBD4A8EFD9D111BA7300A0C927DADB563094@xcgmd008.md.essd.northgrum.com> I've been thinking about setting permissions via Samba now, and I'm convinced that 'create mask' was not originally intended (looking at the implementation) to be anything more than a umask. It really should not be used to prevent users from changing the premissions on existing files (as is the behavor in 2.0.4), since the umask is always going to be more paranoid than the least paranoid permissions the users would want to set (it had better be, in fact, if you care about security), and that's not the intended purpose of the umask anyway. Jeremy did suggest a 'security mask' parameter that would restrict the permissions a user could set, I think entirely independently of the umask. Which is probably the right thing to do. Only thing is, now I'm having a hard time coming up with a rationale for even having a 'security mask'-like parameter. It's probably related to the rationale behind the 'force mode' parameter, which I can't justify to myself right now either. Obviously someone wanted or needed it, though; I'm kind of curious who uses 'force mode', and for what... From davecb at canada.sun.com Fri Jun 18 16:48:46 1999 From: davecb at canada.sun.com (David Collier-Brown) Date: Tue Dec 2 03:03:07 2003 Subject: more thoughts on Samba permissions manipulation References: <51FBD4A8EFD9D111BA7300A0C927DADB563094@xcgmd008.md.essd.northgrum.com> Message-ID: <376A786E.548533E2@canada.sun.com> Cole, Timothy D. wrote: > Only thing is, now I'm having a hard time coming up with a rationale for > even having a 'security mask'-like parameter. It's probably related to the > rationale behind the 'force mode' parameter, which I can't justify to myself > right now either. Obviously someone wanted or needed it, though; I'm kind > of curious who uses 'force mode', and for what... We use it to force group write on files which are maniplated by a PC program: they're initially group-writable, until someone edits them with the PC program, which renames them to .BAK, and creates a new file . with the default permissions and ownerships and the changed data. This destroys the previous ownership and permissions, so no-one else can edit the files! Therefor we force group write on all files created in that share. By the way, the Eunuch programs which manipulate the files make a copy named .BAK, and then read from it and write to . when changing their contents. This doesn't blow the ownerships and permissions away. --dave -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | http://java.science.yorku.ca/~davecb Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb@canada.sun.com From timothy_d_cole at md.northgrum.com Fri Jun 18 17:01:14 1999 From: timothy_d_cole at md.northgrum.com (Cole, Timothy D.) Date: Tue Dec 2 03:03:07 2003 Subject: force mode (Was: RE: more thoughts on Samba permissions manipulat ion) Message-ID: <51FBD4A8EFD9D111BA7300A0C927DADB563095@xcgmd008.md.essd.northgrum.com> > -----Original Message----- > From: David Collier-Brown [SMTP:davecb@canada.sun.com] > Sent: Friday, June 18, 1999 12:49 > To: timothy_d_cole@md.northgrum.com > Cc: Multiple recipients of list > Subject: Re: more thoughts on Samba permissions manipulation > > Cole, Timothy D. wrote: > > Only thing is, now I'm having a hard time coming up with a rationale for > > even having a 'security mask'-like parameter. It's probably related to > the > > rationale behind the 'force mode' parameter, which I can't justify to > myself > > right now either. Obviously someone wanted or needed it, though; I'm > kind > > of curious who uses 'force mode', and for what... > > We use it to force group write on files which are maniplated > by a PC program: they're initially group-writable, until > someone edits them with the PC program, which renames them > to .BAK, and creates a new file . with the > default permissions and ownerships and the changed data. > > This destroys the previous ownership and permissions, so > no-one else can edit the files! Therefor we force group write > on all files created in that share. > Ah, that makes sense. Thank you. > By the way, the Eunuch programs which manipulate the files > make a copy named .BAK, and then read from it and > write to . when changing their contents. This > doesn't blow the ownerships and permissions away. > *sigh* indeed... why can't PC software vendors get these kind of things right? I know they've been dealing with DOS for the past ten years, but even so... Hrm. The intended use of force mode, then, is also file creation. Getting back to the 'security mask' and 'security force mode' things, can anyone come up with any scenarios where limiting the permissions that can be explicitly set via the SMB interface is useful, without giving the admin a false sense of security? From davecb at canada.sun.com Fri Jun 18 17:15:45 1999 From: davecb at canada.sun.com (David Collier-Brown) Date: Tue Dec 2 03:03:07 2003 Subject: force mode References: <51FBD4A8EFD9D111BA7300A0C927DADB563095@xcgmd008.md.essd.northgrum.com> Message-ID: <376A7EC0.7BCFDBCF@canada.sun.com> Cole, Timothy D. wrote: > Hrm. The intended use of force mode, then, is also file creation. > Getting back to the 'security mask' and 'security force mode' things, can > anyone come up with any scenarios where limiting the permissions that can be > explicitly set via the SMB interface is useful, without giving the admin a > false sense of security? I think I've missed something in this discussion somewhere: if I can set specific permission bits with "force create mode" unset others with "create mode", then what then can't I do at file-creation time? It looks like I can constrain the user to set or not set anything I want, which makes me the final arbiter of the permissions. This also adress the case of an implicit creation (ie, the PC program creating a new fild during editing). It does no t address the case of a user changing permissions, but then we're not discussing that yet.... So it looks like the only other possible thing I might want is a value to set an initial value, in the equation result = (initial & mask) | force --dave (feeling fairly stupid this week) c-b -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | http://java.science.yorku.ca/~davecb Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb@canada.sun.com From timothy_d_cole at md.northgrum.com Fri Jun 18 17:28:01 1999 From: timothy_d_cole at md.northgrum.com (Cole, Timothy D.) Date: Tue Dec 2 03:03:07 2003 Subject: force mode Message-ID: <51FBD4A8EFD9D111BA7300A0C927DADB563096@xcgmd008.md.essd.northgrum.com> > -----Original Message----- > From: David Collier-Brown [SMTP:davecb@canada.sun.com] > Sent: Friday, June 18, 1999 13:16 > To: Cole, Timothy D.; Multiple recipients of list > Subject: Re: force mode > > Cole, Timothy D. wrote: > > Hrm. The intended use of force mode, then, is also file > creation. > > Getting back to the 'security mask' and 'security force mode' things, > can > > anyone come up with any scenarios where limiting the permissions that > can be > > explicitly set via the SMB interface is useful, without giving the admin > a > > false sense of security? > > I think I've missed something in this discussion somewhere: > if I can > set specific permission bits with "force create mode" > unset others with "create mode", > then what then can't I do at file-creation time? It looks > like I can constrain the user to set or not set anything I want, > which makes me the final arbiter of the permissions. > > This also adress the case of an implicit creation (ie, the > PC program creating a new fild during editing). It does no > t address the case of a user changing permissions, but then > we're not discussing that yet.... > > Actually, we are ... I'm afraid I transitioned back to that topic in the > second sentence up there without flagging it very well. > > So it looks like the only other possible thing I might > want is a value to set an initial value, in the equation > result = (initial & mask) | force > > Hmm... for file creation, you ought to be able to synthesize that with > force alone. > From branko.cibej at hermes.si Fri Jun 18 18:31:32 1999 From: branko.cibej at hermes.si (Branko Cibej) Date: Tue Dec 2 03:03:07 2003 Subject: force mode (Was: RE: more thoughts on Samba permissions manipulat References: <51FBD4A8EFD9D111BA7300A0C927DADB563095@xcgmd008.md.essd.northgrum.com> Message-ID: <376A9084.3E21E5CA@hermes.si> > > We use it to force group write on files which are maniplated > > by a PC program: they're initially group-writable, until > > someone edits them with the PC program, which renames them > > to .BAK, and creates a new file . with the > > default permissions and ownerships and the changed data. > > > > This destroys the previous ownership and permissions, so > > no-one else can edit the files! Therefor we force group write > > on all files created in that share. > > > Ah, that makes sense. Thank you. > > > By the way, the Eunuch programs which manipulate the files > > make a copy named .BAK, and then read from it and > > write to . when changing their contents. This > > doesn't blow the ownerships and permissions away. > > > *sigh* indeed... why can't PC software vendors get these kind of > things right? I know they've been dealing with DOS for the past ten years, > but even so... Actually, the correct fix for this particular Microsoftish misfeature is to cache the permissions and ownership of deleted files for a few seconds, and restore them if the same file is created again while the info in the cache is still alive. NT 4.0 does something like that with mangled file names: it caches the long->short mapping for a short while, so that it can recreate the original long or short name, and thus keep 16-bit apps that use the weird (stupid, dangerous, race-condition-producing, not-to-be-borne and probably heathen) save algorithm, i.e. old versions of Word, from silently killing off the long file names. Hmmm ... now that I think about it, caching the permissions isn't enough -- you have to preserve hard links, i.e. the node number, too. Which means you have to "logically" delete the file: put it in a table of invisible files, perhaps rename it to, e.g., `.#deleted#', and delay the unlink. Should be fairly easy to do in a VFS module, and the nice thing is that if you're allowed to delete a file, you're also allowed to rename it (don't know about the sticky bit semantics, though). (Yes I've been doing this sort of thing for years now in a versionable file system, for exactly the same reasons ... our customers seem to expect the Office tools to work, gods only know why :-) Brane -- Branko ?ibej HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia voice: (+386 61) 186 53 49 fax: (+386 61) 186 52 70 From ejajko at corp.auspex.com Fri Jun 18 19:49:38 1999 From: ejajko at corp.auspex.com (Edward Jajko) Date: Tue Dec 2 03:03:07 2003 Subject: force mode (Was: RE: more thoughts on Samba permissions manipulat Message-ID: <199906181949.MAA20414@ejajko.auspex.com> :)From branko.cibej@hermes.si Fri Jun 18 11:31:56 1999 :)Subject: Re: force mode (Was: RE: more thoughts on Samba permissions manipulat :)> *sigh* indeed... why can't PC software vendors get these kind of :)> things right? I know they've been dealing with DOS for the past ten years, :)> but even so... :) :)Actually, the correct fix for this particular Microsoftish misfeature is to :)cache the permissions and ownership of deleted files for a few seconds, and :)restore them if the same file is created again while the info in the cache is :)still alive. This sounds like a very nasty security hole- if one were to do this, you should at least force a restriction to a nonprivileged account. :) :)Hmmm ... now that I think about it, caching the permissions isn't enough -- you :)have to preserve hard links, i.e. the node number, too. Which means you have to :)"logically" delete the file: put it in a table of invisible files, perhaps :)rename it to, e.g., `.#deleted#', and delay the unlink. Should be :)fairly easy to do in a VFS module, and the nice thing is that if you're allowed :)to delete a file, you're also allowed to rename it (don't know about the sticky :)bit semantics, though). And this sounds like the biggest security hole yet ;) From branko.cibej at hermes.si Fri Jun 18 20:17:20 1999 From: branko.cibej at hermes.si (Branko Cibej) Date: Tue Dec 2 03:03:07 2003 Subject: force mode (Was: RE: more thoughts on Samba permissions manipulat References: <199906181949.MAA20414@ejajko.auspex.com> Message-ID: <376AA950.D9A2B99@hermes.si> Edward Jajko wrote: > :)Actually, the correct fix for this particular Microsoftish misfeature is to > :)cache the permissions and ownership of deleted files for a few seconds, and > :)restore them if the same file is created again while the info in the cache is > :)still alive. > > This sounds like a very nasty security hole- if one were to do this, you > should at least force a restriction to a nonprivileged account. Well ... > :)Hmmm ... now that I think about it, caching the permissions isn't enough -- you > :)have to preserve hard links, i.e. the node number, too. Which means you have to > :)"logically" delete the file: put it in a table of invisible files, perhaps > :)rename it to, e.g., `.#deleted#', and delay the unlink. Should be > :)fairly easy to do in a VFS module, and the nice thing is that if you're allowed > :)to delete a file, you're also allowed to rename it (don't know about the sticky > :)bit semantics, though). > > And this sounds like the biggest security hole yet ;) ... yes and no: * the cache must be per-process -- only the user who deleted the file may create it again; * she must also have read and write permission to the file (the latter is required by CIFS for delete, I think). So the security hole is as large as the administrator makes it. There are already other such potential holes, such as "force user = root", f'r instance :-) If VFS modules are service-specific, and no ordinary user can edit the config files, I think you can make it safe. Brane -- Branko ?ibej HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia voice: (+386 61) 186 53 49 fax: (+386 61) 186 52 70 From timothy_d_cole at md.northgrum.com Fri Jun 18 20:09:16 1999 From: timothy_d_cole at md.northgrum.com (Cole, Timothy D.) Date: Tue Dec 2 03:03:07 2003 Subject: force mode (Was: RE: more thoughts on Samba permissions manip ulat Message-ID: <51FBD4A8EFD9D111BA7300A0C927DADB563097@xcgmd008.md.essd.northgrum.com> > -----Original Message----- > From: ejajko@corp.auspex.com [SMTP:ejajko@corp.auspex.com] > Sent: Friday, June 18, 1999 15:54 > To: Multiple recipients of list > Subject: Re: force mode (Was: RE: more thoughts on Samba permissions > manipulat > > :)From branko.cibej@hermes.si Fri Jun 18 11:31:56 1999 > :)Subject: Re: force mode (Was: RE: more thoughts on Samba permissions > manipulat > :)> *sigh* indeed... why can't PC software vendors get these > kind of > :)> things right? I know they've been dealing with DOS for the past ten > years, > :)> but even so... > :) > :)Actually, the correct fix for this particular Microsoftish misfeature is > to > :)cache the permissions and ownership of deleted files for a few seconds, > and > :)restore them if the same file is created again while the info in the > cache is > :)still alive. > > This sounds like a very nasty security hole- if one were to do this, you > should at least force a restriction to a nonprivileged account. > The cache he refers to is probably local to the individual session/user/app combination. > :)Hmmm ... now that I think about it, caching the permissions isn't enough > -- you > :)have to preserve hard links, i.e. the node number, too. Which means you > have to > :)"logically" delete the file: put it in a table of invisible files, > perhaps > :)rename it to, e.g., `.#deleted#', and delay the unlink. Should > be > :)fairly easy to do in a VFS module, and the nice thing is that if you're > allowed > :)to delete a file, you're also allowed to rename it (don't know about the > sticky > :)bit semantics, though). > > And this sounds like the biggest security hole yet ;) > I'm not exactly sure how explotiable that would in fact be; at worst, if the other party won the race, the rename would either nuke their link, or fail. And of course the permissions would remain the same, so they wouldn't exactly get access to anything that they didn't have before. In any case, some NFS implementations do something like this anyway (for different reasons). From sharpe at ns.aus.com Sat Jun 19 15:22:26 1999 From: sharpe at ns.aus.com (Richard Sharpe) Date: Tue Dec 2 03:03:07 2003 Subject: Problems compiling smbmount etc Message-ID: <3.0.5.32.19990620002226.009294f0@mail.adelaide.on.net> >Date: Sat, 19 Jun 1999 23:17:37 +0930 >From: Mark Williams >Subject: Ooppps.... Sorry about the HTML.... Here's the email again. >To: Richard Sharpe >X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2014.211 >X-Mailer: Microsoft Outlook Express 5.00.2014.211 >X-MSMail-priority: Normal >Original-recipient: rfc822;rsharpe@ns.aus.com > >Since ive seen you around on the SA Mailing list and your a part of the >samba team, I though you might be able to help me with a few of my samba >problems. > >1/ >I think I found something overlooked in the samba source (nttrans.c and >open.c). When NT5 tries to open a directory in the samba log it says samba >is trying to open a file. I gather this is actually a NT5 problem rather >than a samba problem, but I have found that the nttrans.c source overlooks >this error and continues trying to open the dir as a file anyway. >I have made a very sloppy fix for this problem which seems to have worked. >If you want more particulars please ask. > >2/ >I have the source in tarball and SRPM (ver 2.0.4b). When I try and make the >source from either package, I find that smbmount and smbmnt are not compiled >(smbclient is compiled though). >I try "make bin/smbmnt" and then it compiles smbmnt fine. But when I try >"make bin/smbmount" I get a lot of code errors (10 warnings to be precise). >Consequently, smbmount is not made. >I have not looked at the code but I thought i should point these errors out >(BTW... im using RH6.0, 2.2.9, and PGCC). >Anything I can do for a "quick fix"? > >3/ >I have found that NT5 (Windows2000 build 2031) makes lots of >"NT_TRANS_IOCTL" calls (which in 2.0.4b isnt implemented). >Becuse of this, I get very large NT5 delays (and lockups). It looks like it >will need to be implemented in the next version of samba, for samba to >remain compatible with NT5. > >Thanks for reading my ramble, > Mark Williams > > Regards ------- Richard Sharpe, sharpe@ns.aus.com, NS Computer Software and Services P/L, Samba (Team member www.samba.org), Ethereal (Team member www.zing.org) Co-author, SAMS Teach Yourself Samba in 24 Hours From alan_k at hklc.com Sun Jun 20 10:59:17 1999 From: alan_k at hklc.com (Alan Knowles) Date: Tue Dec 2 03:03:07 2003 Subject: need undelete function (Jeremy, what is your idea?) Message-ID: Has anybody investigated the undelete utils that where written for ext2fs? http://amadeus.upr.clu.edu/~undelete/ these use the chattr +u extended attributes, dump everything into a temporary folder, and manage the deleted file/folder size... It's a bit beyond my testing abilities... but has anyone tryed it.. regards alan -- Linux Center (HK) Ltd. - Center of Excellence Bringing you tommorows OS today. www.hklc.com alan_k@hklc.com www.hklc.com/infocenter Alan's linux infocenter From noc at intc.net Sun Jun 20 16:30:56 1999 From: noc at intc.net (INTC Network Operations) Date: Tue Dec 2 03:03:07 2003 Subject: locking bug in libsmb/clientgen.c ??? Message-ID: Greetings, Hopefully this is of the proper magnitude and substance for posting to samba-technical and submission to samba-bugs as opposed to the help/admin list. My apologies for posting without lurking first, especially to a development list! BACKGROUND ---------- - Linux 2.0.35 - Samba 2.0.4b - i386 architecture - compiled with ecgs 1.0.3 PROBLEM ------- - complaints of file corruption when multiple users access files simultaneously - I can attempt to get smbstatus lock status info if desired/needed. WHAT I FOUND ------------ - lock2, unlock1, and lock3 succeed in smbtorture's run_locktest2 [lock2 succeeded] It seems to me from smbtorture.c that the smb server is not failing overlapping locks (with different int values returned by cli_open) when made by the same pid. [unlock1 succeeded] A pid can unlock another pid's lock. [lock3 succeeded] Lock request from another pid succeeds; is this because the prior unlock succeeded, or would it happen anyway? - "error: lock3 0 succeeded" in smbtorture's run_locktest3 [lock3 0 succeeded] I'm not sure I entirely understand this. I skimmed the 'for' loop, but thought it best to ask outside advice. I've looked at cli_lock and cli_unlock in libsmb/clientgen.c, and I cannot see any locking allow/disallow intelligence. WHAT TO DO? ----------- I attempted to start writing an "unposixlock.c" module to handle these things (via, say, shared memory) but... interfacing with existing Samba code? proper SMB behavior and response to send? I think I need some advice and some help. I don't mind cutting code, not in the least, but I want to make sure that I am coding in the right direction. :) TIA, Eddy *-----------------------------\_/~~\_/----------------------------------* Edward Brotsman Dreger "Your Success is Our Success Network & Systems Manager Our Expertise is Your Advantage" Brian's Consulting Services /~\__/~\ www.brics.com * 316-794-8922 _________________________________________________________________________ SPAMbot bait: abuse@localhost postmaster@localhost blacklist@brics.com From Tim.Potter at anu.edu.au Mon Jun 21 01:54:34 1999 From: Tim.Potter at anu.edu.au (Tim Potter) Date: Tue Dec 2 03:03:07 2003 Subject: VFS stuff (was Re: need undelete function) In-Reply-To: <37690363.CB55CDBE@reac.com> References: <14184.43468.672682.685255@acronym.anu.edu.au> <37690363.CB55CDBE@reac.com> Message-ID: <14189.39770.149786.83330@acronym.anu.edu.au> Andy Bakun writes: > I am in total agreement on the scripting VFS module. I've been > getting requests to implement a bunch of things similar to my 'close > command' patch (http://www.reac.com/samba/samba-closecmd.README), > but I'm holding out until the VFS layer that was talked about a few > months ago goes gold, because this is a more 'correct' way to do it, > in my mind. I'll use this post as a sounding board for some of my > ideas. :) I havn't heard much about the VFS layer in a while; is it > already in the 2.1 series? Did the developer give up on it? Who > was working on it anyway? I'd be willing to implement it if I > wasn't duplicating work. Tim, your post seems to indicate that VFS > stuff is already written -- am I completely out of the loop? Is > there documentation for what's already written? To answer your questions, the VFS layer has been merged into the head branch (i.e samba 2.1) and some bugs that I didn't catch have been found in typical open source (!tm) fashion thanks to Jean-Francois and Matt Chapman. If you're looking for documentation, there isn't terribly much at the moment. Check out $SAMBA_SRC/examples/VFS for a skeleton VFS module and a module that audits file access to syslog. Things that need doing are: - some more documentation - another layer to hide some of the complexity of working with a file descriptor I/O interface - vfs parameters - stackable VFS modules? > I'd think that the VFS layer can be bound on a per-share basis, thusly: > > [share] > path = /whatever > comment = my share > vfs link against = /usr/local/samba/lib/my-samba-vfs-layer.so This is the way it works - the command is actually 'vfs object'. > A 'execute script' shared lib could be provided for with the samba > distribution. In terms of giving the bound vfs layer configuration > parameters, the conf file parsing code could be modified to take > things of the form: > vfs link against = /path/to/so > { > vfs option one = x > vfs option two = x > } > > I believe this would be easy to implement because the conf file > parsing code could just skip over, and not process, things in > braces; keeping the things in braces as plain text to pass to the My idea was to have a token like 'vfs option' which was skipped over by the option parser but passed to the vfs module as an array of char * on init. I think the braces can simply be left out as vfs options are already easily detactable. So that's where it's at. A couple of people have expressed interested in writing vfs modules. There should be enough info in the examples directory and the source code to get started on something if you're keen. Regards, Tim. > > Andy. > -- Tim Potter, System Admin/Programmer, Head Bee Guy Advanced Computational Systems CRC, RSISE Bldg Australian National University, Canberra 0200, AUSTRALIA Ph: +61 2 62798813 Fax: +61 2 62798602 From pauls at caemrad.com.au Mon Jun 21 05:41:25 1999 From: pauls at caemrad.com.au (Paul Schulz) Date: Tue Dec 2 03:03:07 2003 Subject: NT Terminal Server and Samba Authentication Message-ID: <376DD085.B2B0E87C@caemrad.com.au> Before I describe my problem: What are the best tools/setup for tracing protocol problems between NT and Samba? (tcpdump? ethereal? protocol references?) An NT Termial Server (essential NT 4, but no way of being sure about it with M$) talks to a Samba 2.0.0. I have enabled 'plain text passwords' on the NT machine so that Samba can authenticate against NIS for its 'shares'. Samba will ask for a password, before allowing access to it's shares (security=user) Problem: Sometimes a user will be refused a connection.. repeatedly popping up a password window. Workaround 1: Stop and start Samba - This will allow that password to be accepted, but affects other users on Windows 95 machines.. who loose their connections. Workareound 2: Reboot NT machine and stop and start Samba What's going on? PaulS -- Paul Schulz(pauls@caemrad.com.au) SysAdmin CAE MRad, Innovation House West, First Avenue, TECHNOLOGY PARK SA 5095 -..-.----_...._--..._---_.-----.....---___.,-..----.-,---.-.--__._.... From davecb at canada.sun.com Mon Jun 21 12:16:00 1999 From: davecb at canada.sun.com (David Collier-Brown) Date: Tue Dec 2 03:03:07 2003 Subject: force mode (Was: RE: more thoughts on Samba permissions manip References: <51FBD4A8EFD9D111BA7300A0C927DADB563097@xcgmd008.md.essd.northgrum.com> Message-ID: <376E2D00.E393D0C6@canada.sun.com> ejajko@corp.auspex.com [SMTP:ejajko@corp.auspex.com] wrote: > > And this sounds like the biggest security hole yet ;) [In reference to saving and recreating the file] Cole, Timothy D. wrote: > I'm not exactly sure how exploitable that would in fact be; at > worst, if the other party won the race, the rename would either nuke their > link, or fail. And of course the permissions would remain the same, so they > wouldn't exactly get access to anything that they didn't have before. In > any case, some NFS implementations do something like this anyway (for > different reasons). Agreed: we're looking for a race-condition attack in delete p create p where delete p::= link p q actually delete p and create p ::= if p identically equal q mv p q There is no new window within the operations of delete and create, so the risk is where you'd expect it, between them. The attack is to move a new file , r, into the place of p However, to have the permissions to do that means you have permissions to do "mv r p". This reduces it to a quality-of-implementation problem, ensuring that the deleted file isn't placed into some more general trachcan where someone might inadvertently grab q during the window, causing an unintentional deletion of all the permissions and links. --dave [Pretending to be my "evil twin", an academic colleague with a similar name who insists on working gall problems out from first principles every time they're raised] -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | http://java.science.yorku.ca/~davecb Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb@canada.sun.com From davecb at canada.sun.com Mon Jun 21 12:36:30 1999 From: davecb at canada.sun.com (David Collier-Brown) Date: Tue Dec 2 03:03:07 2003 Subject: force mode (Was: RE: more thoughts on Samba permissions manip References: <51FBD4A8EFD9D111BA7300A0C927DADB563097@xcgmd008.md.essd.northgrum.com> <376E2D00.E393D0C6@canada.sun.com> Message-ID: <376E31CE.2A7675FD@canada.sun.com> David Collier-Brown wrote: > and create p ::= > if p identically equal q > mv p q s/mv p q/mv q p/ --dave From borsenkow.msk at sni.de Mon Jun 21 15:11:59 1999 From: borsenkow.msk at sni.de (Andrej Borsenkow) Date: Tue Dec 2 03:03:08 2003 Subject: 2.0.4b: file structure leackage. Serious bug! Message-ID: <006101bebbf8$68eabb90$21c9ca95@mow.siemens.ru> This is 2.0.4b + Win2k patch of Matt Chapman. Problem description: trying to extract large (~50M) Zip archive using WinZIP (context explorer menu -> extract to), I got errors: [1999/06/21 17:55:43, 0] smbd/files.c:(85) ERROR! Out of file structures Analysing it, it looks the following problem: WinZIP tries to create directory structure for every extracted file. Every time it does so, SAMBA allocates a file structure for every directory level created - but never frees it at all. So, after WinZIP is through with \a\b\c\d\file SAMBA frees file structure for ``file'' but not structures for a,b,c,d. It is not related to system files - they are properly closed I attach log level 5 that show this. [sorry, I copy this to samba-technical as the last time I never got any response from samba-bugs] regards /andrej -------------- next part -------------- A non-text attachment was scrubbed... Name: smb.filestruct.leak.gz Type: application/x-gzip Size: 11071 bytes Desc: not available Url : http://lists.samba.org/archive/samba-technical/attachments/19990621/f13afbf6/smb.filestruct.leak.bin From abakun at reac.com Mon Jun 21 15:37:48 1999 From: abakun at reac.com (Andy Bakun) Date: Tue Dec 2 03:03:08 2003 Subject: 2.0.4b: file structure leackage. Serious bug! References: <006101bebbf8$68eabb90$21c9ca95@mow.siemens.ru> Message-ID: <376E5C4C.E35C57E1@reac.com> Yeah, I uncovered the same problem when copying data off of my cdrom archive to a samba server. I was provided with patches to help debug the problem, but I went out of town and have not had a chance to apply them and generate the debug logs asked of me. I will get on it and produce the debug logs to speed up fixing this. Sorry for the delay, everyone. Andrej Borsenkow wrote: >This is 2.0.4b + Win2k patch of Matt Chapman. > >Problem description: trying to extract large (~50M) Zip archive using WinZIP >(context explorer menu -> extract to), I got errors: > >[1999/06/21 17:55:43, 0] smbd/files.c:(85) > ERROR! Out of file structures > >Analysing it, it looks the following problem: > >WinZIP tries to create directory structure for every extracted file. Every time >it does so, SAMBA allocates a file structure for every directory level created - >but never frees it at all. So, after WinZIP is through with > >\a\b\c\d\file > >SAMBA frees file structure for ``file'' but not structures for a,b,c,d. > >It is not related to system files - they are properly closed > >I attach log level 5 that show this. > >[sorry, I copy this to samba-technical as the last time I never got any response >from samba-bugs] > >regards > >/andrej From lkcl at switchboard.net Mon Jun 21 16:18:48 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:08 2003 Subject: become_root Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: Luke Kenneth Casson Leighton Subject: Re: Become_ (fwd) Date: Mon, 21 Jun 1999 17:08:13 +0100 (BST) Size: 5280 Url: http://lists.samba.org/archive/samba-technical/attachments/19990621/29870dab/attachment.eml From Jean-Francois.Micouleau at dalalu.fr Mon Jun 21 17:30:04 1999 From: Jean-Francois.Micouleau at dalalu.fr (Jean Francois Micouleau) Date: Tue Dec 2 03:03:08 2003 Subject: smbpasswd problems In-Reply-To: Message-ID: [moved to samba-tech where more appropriate] Is LsaLookupSid() working at all in Samba 2.0.4b ? 'Cause clicking on 'Add' in the security->permission box is returning an RPC error call on my 3 production 2.0.4b machines. J.F. On Tue, 22 Jun 1999, Greg Dickie wrote: > Are you sure that's the condition? Whenever I see something like that it > usually ends up that the next user in the list no longer exists in /etc/passwd > or NIS. > > Could that be your problem as well? > > On 21-Jun-99 Alan Hourihane wrote: > > In 2.0.4b - if you try and set up permissions on > > a directory and then click add, and then show > > users. You only get a list of users out of the > > smbpasswd file until the first machine account. > > > > If I move all users before the first machine account > > I get a complete list of users. > > > > Anybody seen this before ? > > > > Alan. > > --------------------------------------------------------------------- > Greg Dickie > Just A Guy* > *from discreet (the logic is gone) > Montreal > (514) 954-7171 > greg@discreet.com > From greg at discreet.com Mon Jun 21 17:35:13 1999 From: greg at discreet.com (Greg Dickie) Date: Tue Dec 2 03:03:08 2003 Subject: smbpasswd problems In-Reply-To: Message-ID: Yes but I assumed Alan was doing on an NTFS partition & not a samba one. I could be wrong though ;-) Greg On 21-Jun-99 Jean Francois Micouleau wrote: > > [moved to samba-tech where more appropriate] > > Is LsaLookupSid() working at all in Samba 2.0.4b ? > > 'Cause clicking on 'Add' in the security->permission box is returning an > RPC error call on my 3 production 2.0.4b machines. > > J.F. > > On Tue, 22 Jun 1999, Greg Dickie wrote: > >> Are you sure that's the condition? Whenever I see something like that it >> usually ends up that the next user in the list no longer exists in >> /etc/passwd >> or NIS. >> >> Could that be your problem as well? >> >> On 21-Jun-99 Alan Hourihane wrote: >> > In 2.0.4b - if you try and set up permissions on >> > a directory and then click add, and then show >> > users. You only get a list of users out of the >> > smbpasswd file until the first machine account. >> > >> > If I move all users before the first machine account >> > I get a complete list of users. >> > >> > Anybody seen this before ? >> > >> > Alan. >> >> --------------------------------------------------------------------- >> Greg Dickie >> Just A Guy* >> *from discreet (the logic is gone) >> Montreal >> (514) 954-7171 >> greg@discreet.com >> --------------------------------------------------------------------- Greg Dickie Just A Guy* *from discreet (the logic is gone) Montreal (514) 954-7171 greg@discreet.com From lkcl at switchboard.net Mon Jun 21 18:36:10 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:08 2003 Subject: smbpasswd problems In-Reply-To: Message-ID: On Tue, 22 Jun 1999, Jean Francois Micouleau wrote: > > [moved to samba-tech where more appropriate] > > Is LsaLookupSid() working at all in Samba 2.0.4b ? probably not. use code from cvs main. > 'Cause clicking on 'Add' in the security->permission box is returning an > RPC error call on my 3 production 2.0.4b machines. > > J.F. > > On Tue, 22 Jun 1999, Greg Dickie wrote: > > > Are you sure that's the condition? Whenever I see something like that it > > usually ends up that the next user in the list no longer exists in /etc/passwd > > or NIS. > > > > Could that be your problem as well? > > > > On 21-Jun-99 Alan Hourihane wrote: > > > In 2.0.4b - if you try and set up permissions on > > > a directory and then click add, and then show > > > users. You only get a list of users out of the > > > smbpasswd file until the first machine account. > > > > > > If I move all users before the first machine account > > > I get a complete list of users. > > > > > > Anybody seen this before ? > > > > > > Alan. > > > > --------------------------------------------------------------------- > > Greg Dickie > > Just A Guy* > > *from discreet (the logic is gone) > > Montreal > > (514) 954-7171 > > greg@discreet.com > > > > Luke Kenneth Casson Leighton Samba and Network Development Samba Web site ===================================================================== Luke Kenneth Casson Leighton | Direct Dial : (678) 443-6183 Systems Engineer / ISS XForce Team | ISS Front Desk: (678) 443-6000 Internet Security Systems, Inc. | ISS Fax : (678) 443-6477 http://www.iss.net/ *Adaptive Network Security for the Enterprise* ISS Connect - International User Conference - May '99 ===================================================================== From caesmb at lab2.cc.wmich.edu Mon Jun 21 21:48:21 1999 From: caesmb at lab2.cc.wmich.edu (CAE Samba Admin) Date: Tue Dec 2 03:03:08 2003 Subject: preexec broken? Message-ID: Hello, I'm running a PDC off of 2.0.4b (I know, I know...) and am having some trouble with the "preexec" command for making profile directories. It appears as though "preexec" isn't even executing. I've attached my smb.conf file below. The command string shows up okay with "testparm" and everything works great if I stick change it to a "root preexec"; however, there is no need for this script to be run as root and I want to avoid it as such. Yes, I have checked permissions on the script to be executed. I can run the script just fine as a user from a shell. Samba just seems to ignore it though. We even ran "truss" on smbd and it simply doesn't look like preexec is there (no errors, inability to access files, etc). What would be the lowest (ie, most readable) debug log that I could send or make available for some help looking into this? Thanks, Kevin From matty at samba.org Tue Jun 22 03:49:01 1999 From: matty at samba.org (Matt Chapman) Date: Tue Dec 2 03:03:08 2003 Subject: 2.0.4b: file structure leackage. Serious bug! References: <006101bebbf8$68eabb90$21c9ca95@mow.siemens.ru> Message-ID: <376F07AD.198DBC02@samba.org> Andrej, Can you try this patch and tell me if it fixes the problem. Cheers, Matt -- Matthew "Austin" Chapman SysAdmin, Developer, Samba Team Member -------------- next part -------------- --- nttrans.orig Tue Jun 22 13:45:05 1999 +++ nttrans.c Tue Jun 22 13:45:26 1999 @@ -791,6 +791,8 @@ if(oplock_request || (desired_access & (FILE_READ_DATA|FILE_WRITE_DATA| FILE_APPEND_DATA|FILE_READ_ATTRIBUTES|FILE_READ_EA| FILE_WRITE_ATTRIBUTES|FILE_WRITE_EA))) { + file_free(fsp); + restore_case_semantics(file_attributes); SSVAL(outbuf, smb_flg2, FLAGS2_32_BIT_ERROR_CODES); return(ERROR(0, 0xc0000000|NT_STATUS_FILE_IS_A_DIRECTORY)); } From Michael.Povel at hub.de Tue Jun 22 09:44:38 1999 From: Michael.Povel at hub.de (Michael C. Povel) Date: Tue Dec 2 03:03:08 2003 Subject: 2.0.4b: file structure leackage. Serious bug! References: <006101bebbf8$68eabb90$21c9ca95@mow.siemens.ru> <376F07AD.198DBC02@samba.org> Message-ID: <376F5B06.3DC2FD92@hub.de> Hello, I just tried your patch, and it looks like the problem has disapeered. We were able to reproduce the problem very quickly, when using DFS in combination with samba and writable shares. I hope this helps... But we also have got another problem. When we copy a file from a NT-Workstation onto our samba share, the file date an time gets updated, if the sourcefile was on NTFS. If the source cam from FAT everything is correct, an the timestamps are not updated. Any clues ? Thanks Michael From tridge at samba.org Tue Jun 22 11:06:42 1999 From: tridge at samba.org (Andrew Tridgell) Date: Tue Dec 2 03:03:08 2003 Subject: locking bug in libsmb/clientgen.c ??? In-Reply-To: (message from INTC Network Operations on Mon, 21 Jun 1999 02:32:54 +1000) References: Message-ID: <19990622110652Z12861657-9913+3445@samba.anu.edu.au> > - "error: lock3 0 succeeded" in smbtorture's run_locktest3 you probably shouldn't use smbtorture as a guide to what is causing real-world locking problems. smbtorture is there as a reminder to us that smbd doesn't perform exactly to spec on file locking tests, but as far as we know these particular problems don't affect real applications using any of Microsofts clients. That's because MS clients heck for things like a inter-PID intra-client locking conflict and flag it internally so that it never goes over the wire to the server. It would be nice for Samba to get this right itself, but we believe it will make no difference with any MS client. (also note that NT4 and Win9X fail some of the tests in smbtorture as well, it is quite a strict tester). > I've looked at cli_lock and cli_unlock in libsmb/clientgen.c, and I cannot > see any locking allow/disallow intelligence. that's right. Remember that clientgen.c is used by smbclient not smbd I know that's not strictly true, it's used in the browse client and security server code, but for the purposes of this discussion you could consider it true. So if you want to fix a problem noticed by a user using smbd then don't look at clientgen.c :) To actually "fix" the locking bugs pointed out by smbtorture we will need to bypass the normal unix fcntl() lock interface and have our own lock daemon. We want to do this anyway for other reasons (mostly to do with 32/64 bit lock offsets) but it isn't a really high priority as we know of no current application problems that can be caused by the current mechanism. This makes it a "we want to do this right eventually" problem rather than a "oh shit, we better fix this today" problem :) > PROBLEM > ------- > > - complaints of file corruption when multiple users access files > simultaneously we would need some more info about this. Is there any chance it can be explained by normal oplock behaviour? From Michael.Povel at hub.de Tue Jun 22 11:05:28 1999 From: Michael.Povel at hub.de (Michael C. Povel) Date: Tue Dec 2 03:03:08 2003 Subject: NT Timestamps and copy Message-ID: <376F6DF8.356440FE@hub.de> Hello, after searching for a reason of our timechanges, when copying files from a NTFS partition to a samba share, on samba 2.0.4b, I discovered that after setting "nt smb support = No" everything seems to be OK. Without this, the timestamps changed, when copying files from NT4 to samba from a NTFS filesystem..... cu Michael From tridge at samba.org Tue Jun 22 11:22:54 1999 From: tridge at samba.org (Andrew Tridgell) Date: Tue Dec 2 03:03:08 2003 Subject: NT Timestamps and copy In-Reply-To: <376F6DF8.356440FE@hub.de> (Michael.Povel@hub.de) References: <376F6DF8.356440FE@hub.de> Message-ID: <19990622112256Z12861645-13010+3423@samba.anu.edu.au> > after searching for a reason of our timechanges, when copying files > from a NTFS partition to a samba share, on samba 2.0.4b, I discovered > that after setting "nt smb support = No" everything seems to be OK. > Without this, the timestamps changed, when copying files from NT4 to > samba from a NTFS filesystem..... can you explain this in a bit more detail? timestamps seem to be fine when copying from NT4sp4 to Samba here. Perhaps you could give an example? What tool are you using to copy the files? How much are the dates off by? From borsenkow.msk at sni.de Tue Jun 22 12:11:12 1999 From: borsenkow.msk at sni.de (Andrej Borsenkow) Date: Tue Dec 2 03:03:08 2003 Subject: 2.0.4b: file structure leackage. Serious bug! In-Reply-To: <376F07AD.198DBC02@samba.org> Message-ID: <006c01bebca8$5206fd70$21c9ca95@mow.siemens.ru> > > Andrej, > > Can you try this patch and tell me if it fixes the problem. > I could extract the same ZIP archive that was not possible before. So, I tend to say, yes :-) thank you! /andrej From Michael.Povel at hub.de Tue Jun 22 14:00:01 1999 From: Michael.Povel at hub.de (Michael C. Povel) Date: Tue Dec 2 03:03:08 2003 Subject: NT Timestamps and copy References: <376F6DF8.356440FE@hub.de> <19990622112256Z12861645-13010+3423@samba.anu.edu.au> Message-ID: <376F96E1.E9408230@hub.de> Hello, Andrew Tridgell wrote: > > > after searching for a reason of our timechanges, when copying files > > from a NTFS partition to a samba share, on samba 2.0.4b, I discovered > > that after setting "nt smb support = No" everything seems to be OK. > > Without this, the timestamps changed, when copying files from NT4 to > > samba from a NTFS filesystem..... > > can you explain this in a bit more detail? timestamps seem to be fine > when copying from NT4sp4 to Samba here. Perhaps you could give an > example? What tool are you using to copy the files? How much are the > dates off by? We are using samba 2.0.4b as File and Printservers with security=domain. When I copy a file from my workstation to our samba server without any "nt smb support" statement in our smb.conf, the file gets the actual date and time stamp, if it comes from a ntfs filesystem on my workstation. When the file was on a FAT filesystem, and I copy it, the timestamp keeps korrekt, as the of last modufication. It doesn't matter, if I copy the file with the Explorer or with a normal copy command in a 4NT-Box. The problem appears under Linux with glibc and also with libc.5 As mentioned before the main point was the ntfs filesystem on the source, which I don't realy understand.... If you need any more iformation, please mail me. cu Michael From abakun at reac.com Tue Jun 22 16:02:45 1999 From: abakun at reac.com (Andy Bakun) Date: Tue Dec 2 03:03:08 2003 Subject: file structure leackage/out of file structures References: <376F213D.B54DA88C@samba.org> Message-ID: <376FB3A5.F096079E@reac.com> The following patch, provided to me by Matt Chapman, fixes the "Out of file structures!" error I was getting when copying cds to a samba server as documented in http://us1.samba.org/listproc/samba-technical/3728.html With this patch applied, I am unable to reproduce the problem. This fix gets a thumbs-up from me. Matt Chapman wrote: > --- nttrans.orig Tue Jun 22 13:45:05 1999 > +++ nttrans.c Tue Jun 22 13:45:26 1999 > @@ -791,6 +791,8 @@ > if(oplock_request || (desired_access & (FILE_READ_DATA|FILE_WRITE_DATA| > FILE_APPEND_DATA|FILE_READ_ATTRIBUTES|FILE_READ_EA| > FILE_WRITE_ATTRIBUTES|FILE_WRITE_EA))) { > + file_free(fsp); > + restore_case_semantics(file_attributes); > SSVAL(outbuf, smb_flg2, FLAGS2_32_BIT_ERROR_CODES); > return(ERROR(0, 0xc0000000|NT_STATUS_FILE_IS_A_DIRECTORY)); > } From jallison at cthulhu.engr.sgi.com Tue Jun 22 17:14:04 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:08 2003 Subject: Multi-Workgroup DMB ? References: <19990617090318.B22392@trimble.co.nz> Message-ID: <376FC45C.15D013EE@engr.sgi.com> Jason Haar wrote: > > On Thu, Jun 17, 1999 at 03:35:46AM +1000, Luke Kenneth Casson Leighton wrote: > > that version, 1.9.17p10-multi-wg.tar.gz was never merged back into the > > main cvs repository. > > Does this lack of multi-domain support explain the security hole in Samba > where a user with the same usercode in another NT trusted domain can access > the equivalent local domain account under Samba? I've got that problem > here... In 2.0.4b use "allow trusted domains = No" to stop this. Cheers, Jeremy Allison, Samba Team. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From jallison at cthulhu.engr.sgi.com Tue Jun 22 17:50:15 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:08 2003 Subject: more thoughts on Samba permissions manipulation References: <51FBD4A8EFD9D111BA7300A0C927DADB563094@xcgmd008.md.essd.northgrum.com> Message-ID: <376FCCD7.6D13450F@engr.sgi.com> Cole, Timothy D. wrote: > Only thing is, now I'm having a hard time coming up with a rationale for > even having a 'security mask'-like parameter. It's probably related to the > rationale behind the 'force mode' parameter, which I can't justify to myself > right now either. Obviously someone wanted or needed it, though; I'm kind > of curious who uses 'force mode', and for what... Whistle use it to ensure that the 'x' bit can *never* be set on any files sent to their appliance fileserver (that uses FreeBSD). It just makes it that little bit harder to run something as an executable if the security on the box is breached in some way. Jeremy. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From jallison at cthulhu.engr.sgi.com Tue Jun 22 18:41:55 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:08 2003 Subject: 2.0.4b: file structure leackage. Serious bug! References: <006101bebbf8$68eabb90$21c9ca95@mow.siemens.ru> <376E5C4C.E35C57E1@reac.com> Message-ID: <376FD8F3.48B10297@engr.sgi.com> Andy Bakun wrote: > > Yeah, I uncovered the same problem when copying data off of my cdrom > archive to a samba server. I was provided with patches to help debug the > problem, but I went out of town and have not had a chance to apply them and > generate the debug logs asked of me. I will get on it and produce the > debug logs to speed up fixing this. Sorry for the delay, everyone. > > Andrej Borsenkow wrote: > > >This is 2.0.4b + Win2k patch of Matt Chapman. > > > >Problem description: trying to extract large (~50M) Zip archive using > WinZIP > >(context explorer menu -> extract to), I got errors: > > > >[1999/06/21 17:55:43, 0] smbd/files.c:(85) > > ERROR! Out of file structures > > > >Analysing it, it looks the following problem: > > > >WinZIP tries to create directory structure for every extracted file. Every > time > >it does so, SAMBA allocates a file structure for every directory level > created - > >but never frees it at all. So, after WinZIP is through with > > > >\a\b\c\d\file > > > >SAMBA frees file structure for ``file'' but not structures for a,b,c,d. So, does this mean that the client never sends the close calls for the NT SMB directory opens ? Or is it a Samba bug ? More info would be good.... Jeremy. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From jallison at cthulhu.engr.sgi.com Tue Jun 22 19:04:58 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:08 2003 Subject: 2.0.4b: file structure leackage. Serious bug! References: <006c01bebca8$5206fd70$21c9ca95@mow.siemens.ru> Message-ID: <376FDE5A.2B81ADCC@engr.sgi.com> Andrej Borsenkow wrote: > > > > > Andrej, > > > > Can you try this patch and tell me if it fixes the problem. > > > > I could extract the same ZIP archive that was not possible before. So, I tend to > say, yes :-) > > thank you! Yes, dammit, as soon as I saw the patch I realised it was my bug :-) :-). Sorry. Thanks, Jeremy. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From borsenkow.msk at sni.de Wed Jun 23 12:17:44 1999 From: borsenkow.msk at sni.de (Andrej Borsenkow) Date: Tue Dec 2 03:03:08 2003 Subject: Preserve file times in smbclient Message-ID: <002a01bebd72$66147250$21c9ca95@mow.siemens.ru> I find it really unfortunate, that smbclient does not preserve file times. As compared with FTP (where ther is no standard way to get file times) smbclient *does* know them already. Preserving file times may be really critical. Am I the only one who is missing this feature? regards /andrej From borsenkow.msk at sni.de Wed Jun 23 14:23:20 1999 From: borsenkow.msk at sni.de (Andrej Borsenkow) Date: Tue Dec 2 03:03:08 2003 Subject: Short (MS-DOS) names compatibility with NT Message-ID: <003501bebd83$f1ae4cd0$21c9ca95@mow.siemens.ru> It may be not a problem, but if I remember it correctly, SAMBA should build the short names the same as NT (at least, I can recall seeing it in cvs.log). I just happened to notice, that e.g. when you select Properties for the directory 4.0-real is Explorer context menu, the MS-DOS name is shown by NT as 49A6E~1.0-R and by SAMBA as 4~%E.0-R I think, this may really be an issue, as it may prevent transparent moving of application from NT to SAMBA drive. this is with 2.0.4b. regards /andrej From timothy_d_cole at md.northgrum.com Wed Jun 23 15:51:03 1999 From: timothy_d_cole at md.northgrum.com (Cole, Timothy D.) Date: Tue Dec 2 03:03:08 2003 Subject: more thoughts on Samba permissions manipulation Message-ID: <51FBD4A8EFD9D111BA7300A0C927DADB56309A@xcgmd008.md.essd.northgrum.com> Ahh... yes, I suppose it does make more sense in a "network appliance" fileserver-type situation. So far, I've really been approaching it from the perspective of an admin in a more or less normal Unix environment.. > -----Original Message----- > From: Jeremy Allison [SMTP:jallison@cthulhu.engr.sgi.com] > Sent: Tuesday, June 22, 1999 13:50 > To: timothy_d_cole@md.northgrum.com > Cc: Multiple recipients of list > Subject: Re: more thoughts on Samba permissions manipulation > > Cole, Timothy D. wrote: > > > Only thing is, now I'm having a hard time coming up with a rationale for > > even having a 'security mask'-like parameter. It's probably related to > the > > rationale behind the 'force mode' parameter, which I can't justify to > myself > > right now either. Obviously someone wanted or needed it, though; I'm > kind > > of curious who uses 'force mode', and for what... > > Whistle use it to ensure that the 'x' bit can *never* > be set on any files sent to their appliance fileserver > (that uses FreeBSD). It just makes it that little bit > harder to run something as an executable if the security > on the box is breached in some way. > > Jeremy. > > -- > -------------------------------------------------------- > Buying an operating system without source is like buying > a self-assembly Space Shuttle with no instructions. > -------------------------------------------------------- From caesmb at lab2.cc.wmich.edu Wed Jun 23 17:31:39 1999 From: caesmb at lab2.cc.wmich.edu (CAE Samba Admin) Date: Tue Dec 2 03:03:08 2003 Subject: Repost: preexec broken? In-Reply-To: Message-ID: Sorry everyone. It appears as though my smb.conf didn't make it along with the original post. I'm attaching it again. Thanks... >> Hello, >> >> I'm running a PDC off of 2.0.4b (I know, I know...) and am having some >> trouble with the "preexec" command for making profile directories. It >> appears as though "preexec" isn't even executing. I've attached my >> smb.conf file below. The command string shows up okay with "testparm" and >> everything works great if I stick change it to a "root preexec"; however, >> there is no need for this script to be run as root and I want to avoid it >> as such. Yes, I have checked permissions on the script to be executed. I >> can run the script just fine as a user from a shell. Samba just seems to >> ignore it though. We even ran "truss" on smbd and it simply doesn't look >> like preexec is there (no errors, inability to access files, etc). What >> would be the lowest (ie, most readable) debug log that I could send or >> make available for some help looking into this? Cliff Green wrote: >Well, your smb.conf didn't show up. However, let me guess - you're using >the preexec in the [netlogon] share. What happens when you put it in the >[homes] share (and mount the users' home directory in your logon script)? No, it is in the [profile] share, but that is referenced by "logon path". Does the fact that the "preexec" is in a share that NT tried to connect to at login (vs a user from the command line or a login script) have anything to do with it? This seems unlikely because if I try a "net use z: \\server\profile /user:username" from a command prompt, the "preexex" fails as well. Thanks again, Kevin Currie -------------- next part -------------- ; /usr/local/samba/lib/smb.conf ; Samba configuration file for medusa.lab2.cc.wmich.edu ; Created 06/09/99, Kevin Currie ; ----------------- start [global] configuration options ----------------- [global] ; Identification parameters workgroup = UCS-UNIX netbios name = MEDUSA server string = UCS-UNIX Primary Domain Controller ; Browse list parameters ; Note: This establishes Samba as the browse master for it's domain ; and subnet as well as turning on WINS support. The OS level is set ; high enough to beat out NT Server if an election is forced. domain master = yes local master = yes preferred master = yes os level = 65 wins support = yes ; Domain control options security = user domain logons = yes encrypt passwords = yes ; Options facilitating login scripts for domain controlled clients logon script = %a.bat logon drive = h: logon path = \\medusa\profile dos filetime resolution = yes ; Enable automatic printer configuration and support printing = sysv load printers = yes printcap name = lpstat ; Performance tuning oplocks = yes lock directory = /usr/local/samba/var/locks share modes = yes socket options = TCP_NODELAY deadtime = 15 ; Miscellaneous parameters browsable = yes follow symlinks = yes hide dot files = no debug level = 3 ; ----------------- end [global] configuration options ----------------- ; Template share for user home directories [printers] printable = yes path = /usr/local/samba/spool browseable = yes guest ok = no ; Template share for user home directories [homes] comment = Home Directories path = %H browseable = no writable = yes hide dot files = yes create mask = 644 directory mask = 755 ; Share which Win32 clients connect to for login scripts/policies [netlogon] ; Note: The path should be a symlink to a department controlled ; directory elseware on the file system. comment = Logon Scripts path = /home6/samba/%m$/netlogon force user = nobody public = yes read only = yes follow symlinks = yes locking = no ; Share for user profiles [profile] ; Note: This exists because NT has a bug which maintains a connection ; to \\server\homes even after a user logs out which causes security ; problems with profiles comment = User Profiles path = %H/win32/profile force create mode = 0644 force directory mode = 0755 browseable = no public = no writable = yes follow symlinks = yes ; Note: This just ensures that the necessary directories exist. ; This script should be reviewed by the sysadmin, but is considered ; safe as it is executed as the connecting user preexec = /usr/local/samba/scripts/profile.sh %U %G %H From Marc.DeBonis at vt.edu Wed Jun 23 20:47:18 1999 From: Marc.DeBonis at vt.edu (Marc DeBonis) Date: Tue Dec 2 03:03:08 2003 Subject: Mac OS X SAMBA 2.0.3 time test Message-ID: <4.1.19990623164510.00b28620@mail.vt.edu> I'm not sure if this is the right Samba list to send this data to, but I thought it might be interesting for samba people to look at. Note the brain dead performance with Windows 98 and Samba 2.0.3 on a 100MB pipe. :( --snip-- SMB/CIFS time trials ------------------- Goal: To do file transfer time tests between NT servers native SMB/CIFS services and that of Mac OSX Samba SMB/CIFS services. Estimated results is that Samba is ~25% slower than NT server native. Using NT and 98 clients. ------------------- Machine A DELL 4300 P2-400 128MB RAM 9GB RAID 5 HD 32MB cache SCSI NT SRV 4.0 SP5 Machine B Mac G3 PPC 750 400MHZ 256MB RAM 9GB HD SCSI MAC OSX 1.0.1 SAMBA 2.0.3 Machine C Homemade P-100 32MB RAM 18GB HD SCSI NT SRV 4.0 SP4 Machine D IBM Thinkpad 600 P2-266 96MB 4GB HD ATA IDE Windows 98 ------------------- Package 1 14 files ~10MB each 126MB total Package 2 15 files ~5MB each 60.2MB total Package 3 31 files ~1MB each 41.8MB total Package 4 47 files ~4MB each 214MB total ------------------- Lingo: X write Y to Z (from machine X paste directory containing package Y to machine Z) X read Y from Z (from machine X copy directory containing package Y from machine Z) ------------------- Private 10MB shared ethernet subnet Private 100MB shared ethernet subnet [ client writes to server ] [ client writes to server ] C write 1 to A - 130 sec C write 1 to A - 65 sec (~25% net util) C write 1 to B - 130 sec C write 1 to B - 27 sec (~35% net util) C write 2 to B - 60 sec C write 2 to B - 14 sec (same %s) C write 2 to A - 60 sec C write 2 to A - 40 sec C write 3 to A - 45 sec C write 3 to A - 20 sec C write 3 to B - 45 sec C write 3 to B - 11 sec [ client reads from server ] [ client reads from server ] C read 3 from B - 43 sec C read 3 from B - 12 sec (~35% net util) C read 3 from A - 41 sec C read 3 from A - 12 sec (~35% net util) C read 1 from A - 120 sec C read 1 from A - 28 sec (same %s) C read 1 from B - 126 sec C read 1 from B - 28 sec C read 2 from B - 60 sec C read 2 from B - 15 sec C read 2 from A - 58 sec C read 2 from A - 15 sec [ server writes to server ] [ server writes to server ] A write 4 to B - 210 sec A write 4 to B - 36 sec (>55% net util) [ server reads from server ] [ server reads from server ] A reads 4 from B - 216 sec A reads 4 from B - 200 sec (delayed writes) ------------------- ------------------- Private 10MB shared ethernet subnet Private 100MB shared ethernet subnet [ client writes to server ] [ client writes to server ] D write 1 to A - 153 sec D write 1 to A - 78 sec (~5% net util) D write 1 to B - 163 sec D write 1 to B - 405 sec (0% net util!) D write 2 to B - 74 sec D write 2 to B - 193 sec (!) D write 2 to A - 73 sec D write 2 to A - 36 sec D write 3 to A - 48 sec D write 3 to A - 30 sec D write 3 to B - 49 sec D write 3 to B - 132 sec (!) [ client reads from server ] [ client reads from server ] D read 3 from B - 49 sec D read 3 from B - 18 sec (~35% net util) D read 3 from A - 47 sec D read 3 from A - 17 sec (~35% net util) D read 1 from A - 142 sec D read 1 from A - 51 sec (same %s) D read 1 from B - 148 sec D read 1 from B - 52 sec D read 2 from B - 71 sec D read 2 from B - 26 sec D read 2 from A - 68 sec D read 2 from A - 25 sec ------------------- Observations: 01 - From an NT client, there is very little noticeable difference between reading and writing from/to a NT native or SAMBA implementation of SMB/CIFS. 02 - SAMBA utilized bandwidth better than NT server when an NT client writes to it on a 100MB pipe. 03 - Raid 5 is the NT server's bottleneck when reading on a 100MB pipe. 04 - A windows 98 client acts brain dead when writing to a SAMBA server on a 100MB pipe (much worse than writing to a SAMBA server on a 10MB pipe)! 05 - Neither disk nor memory caching seemed to come into play in these tests. 06 - This test did not study multi-user read/writes, possible memory problems with SAMBA when it forks a smbd for each user? 07 - This test did not study network congestion, read/write retries, or multiple client versions connecting at once. ------------------- Results: Samba 2.0.3 is a pretty slick implementation of SMB/CIFS. The price can't be beat (free), but Samba will require more administration/setup since it's interface is much more difficult to use than the PnC (point and click) gui of NT. While this may be daunting to NT PnC admins, Samba also gives fine grain access to the mechanisms of SMB/CIFS for fine tuning. For the purposes of read only file services, MAC OSX and SAMBA seem to be a fine match against NT server native SMB/CIFS. The only outlier is the bizarre result with the 98 clients on the 100MB pipe. More extensive testing need to be done at the level of Apple Computer to reproduce business standardized results. Apple should really push the easy of use of MAC OSX and the lower price point when considering NT's proclivity to BSOD weekly, the requirement to buy CALS, and its constant security problems. ------------------- - Marc DeBonis (Marc.DeBonis@vt.edu) written 990525 v1.0 Virginia Tech / AIS-TS -- Marc 'Doc' DeBonis [Email: Marc.DeBonis@vt.edu (PGP/SMIME on rqst)] Programmer Analyst, Sr. [AIS-Technical Support Virginia Tech (VPI&SU)] "Absit prudentia nil rei publicae profitur" "Alterius non sit qui suus esse potest" -\|/- From lkcl at switchboard.net Wed Jun 23 20:59:56 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:08 2003 Subject: Mac OS X SAMBA 2.0.3 time test In-Reply-To: <4.1.19990623164510.00b28620@mail.vt.edu> Message-ID: > 06 - This test did not study multi-user read/writes, possible memory > problems with > SAMBA when it forks a smbd for each user? need 600-800k per simultaneous smb process. if you don't do this, you'll end up spending time swapping. if you have a brain-dead or mis-configured OS, you will end up with poor performance. suggest that the smb.conf file is made available to this list, plus more configuration details (os, box etc). suggest also requesting assistance for these kinds of tests, on the samba lists. publication of test results can therefore provide optimal configuration details, which makes publication of the tests far more useful. providing just the numbers, with no config info, is a really bad idea, as it misleads people. luke From shane at hunsley.demon.co.uk Wed Jun 23 22:42:28 1999 From: shane at hunsley.demon.co.uk (Shane Hunsley) Date: Tue Dec 2 03:03:08 2003 Subject: Enhancement Suggestion Message-ID: <000a01bebdc9$acfb7770$4621989e@asus> Hello Would it be possible to add the following functionality to the Samba code. What I'm looking for is the ability to execute a shell script whenever a file has been "created". This would be a share specific parameter called possibly "creation event script". What I want to achieve is to create service specific shares e.g. a share specifically to create zip files. The user would drag and drop the files onto the share and the specified shell script will receive though variable substitution the file name and compress each file using a zip program and then possibly delete the original file leaving only the .zip file for each of the files. Other examples that could use this idea include a file converter e.g. foo.jpg to foo.ps, an unzip share being the opposite of the zip share leaving the user to then move the uncompressed files elsewhere, an automated ftp transfer to specific sites. Other "events" like renaming and deleting would also be useful e.g. an indexing engine for html or even (shudder) Office 2000 HTML documents. I realise some of this could be done with shell scripts and the cron daemon but the events method allows for more controlled execution. Please understand I'm not looking for Samba to actually do the work e.g compression but only to pass the name of the file created to the specified shell script used to action the event. The shell script will be responsible for all the work. It would also be responsible for any logic decisions such as not compressing .zip or .jpg files and in those cases the file would be left. The shell script could then send an e-mail informing the user the zipping or unzipping or whatever task was required has completed. Also the use of shell scripts leaves the actual implementation in the hands of the System Administrator. This idea came about when I our ISDN link was up for long periods because of users sending extremely large attachments. It turns out many of our users find compressing documents a difficult task. The idea of drag and drop files onto a Samba share and the zip files being created for them so they can them drag and drop into Outlook is very interesting. It is certainly not something that can be done easily with NT. I welcome any comment on this concept. Regards, Shane Hunsley -------------- next part -------------- HTML attachment scrubbed and removed From shane at hunsley.demon.co.uk Wed Jun 23 23:09:59 1999 From: shane at hunsley.demon.co.uk (Shane Hunsley) Date: Tue Dec 2 03:03:08 2003 Subject: Enhancement Suggestion In-Reply-To: <000a01bebdc9$acfb7770$4621989e@asus> Message-ID: <001001bebdcd$84f003a0$4621989e@asus> Hello Sorry about the format of my original post. Will send in plain text in future. Regards, Shane Hunsley From matthias at waechter.wol.at Thu Jun 24 00:32:31 1999 From: matthias at waechter.wol.at (=?iso-8859-1?Q?Matthias_W=E4chter?=) Date: Tue Dec 2 03:03:08 2003 Subject: Mac OS X SAMBA 2.0.3 time test In-Reply-To: Message-ID: On Thu, 24 Jun 1999, Luke Kenneth Casson Leighton wrote: > > 06 - This test did not study multi-user read/writes, possible memory > > problems with > > SAMBA when it forks a smbd for each user? > > need 600-800k per simultaneous smb process. if you don't do this, you'll > end up spending time swapping. Are there any estimates for NT Server on this issue to compare to? Means: Does NT also need such (large?) amount of memory per session? Or is this topic another one to take in account when deciding whether to use Samba instead of NT? Sehr Wus, - Matthias -- Bunt ist das Dasein und granatenstark. Und: Volle Kanne, Hoschis! aus: "Bill und Teds verr?ckte Reise durch die Zeit" ----------------------------------------------------------------------------- From turnerjh at pattern.net Thu Jun 24 04:19:42 1999 From: turnerjh at pattern.net (James Turner) Date: Tue Dec 2 03:03:08 2003 Subject: Patch for slow smbclient performance Message-ID: I sent this to the list a while back, but I don't think it made it through for some reason, so here it is again. Below is a patch against samba 2.0.4b that adds a switch to smbclient. I've found that using smbclient to access some Win95 machines is incredibly slow -- 10k/second or worse. The problem doesn't seem to occur when the access occur through smbd. Using strace and gdb revealed the problem to be in the network read/write size. This patch sets it ot be configurable via '-b'. Experimentation has shown some quite peculiar results. Basically the breakpoint is around 1200 bytes for -b. Above it, and you get 10k/sec. Below and you get 400-900k/sec(!). It's not a continuous change; it's quite a jump for a change in one byte. I don't know what value this might have for fixing the poor Win98 performance, but it would seem that Win95 has problems with some patch sizes. Without further adieu, the patch. diff -u --recursive --new-file samba-2.0.4b/source/client/client.c samba-2.0.4b-patched/source/client/client.c --- samba-2.0.4b/source/client/client.c Mon May 17 18:28:10 1999 +++ samba-2.0.4b-patched/source/client/client.c Thu May 27 22:05:57 1999 @@ -41,6 +41,7 @@ static pstring workgroup; static char *cmdstr; static BOOL got_pass; +static int io_bufsize = 65520; extern struct in_addr ipzero; extern pstring scope; @@ -635,7 +636,7 @@ BOOL newhandle = False; char *data; struct timeval tp_start; - int read_size = 65520; + int read_size = io_bufsize; uint16 attr; size_t size; off_t nread = 0; @@ -966,7 +967,7 @@ FILE *f; int nread=0; char *buf=NULL; - int maxwrite=65520; + int maxwrite=io_bufsize; struct timeval tp_start; GetTimeOfDay(&tp_start); @@ -1951,6 +1952,7 @@ DEBUG(0,("\t-TIXFqgbNan command line tar\n")); DEBUG(0,("\t-D directory start from directory\n")); DEBUG(0,("\t-c command string execute semicolon separated commands\n")); + DEBUG(0,("\t-b xmit/send buffer changes the transmit/send buffer (default: 65520)\n")); DEBUG(0,("\n")); } @@ -2236,7 +2238,7 @@ } while ((opt = - getopt(argc, argv,"s:B:O:R:M:i:Nn:d:Pp:l:hI:EU:L:t:m:W:T:D:c:")) != EOF) { + getopt(argc, argv,"s:B:O:R:M:i:Nn:d:Pp:l:hI:EU:L:t:m:W:T:D:c:b:")) != EOF) { switch (opt) { case 's': pstrcpy(servicesf, optarg); @@ -2338,6 +2340,9 @@ cmdstr = optarg; got_pass = True; break; + case 'b': + io_bufsize = MAX(1, atoi(optarg)); + break; default: usage(pname); exit(1); -- Chip Turner turnerjh@pattern.net Programmer, ZFx, Inc. www.zfx.com PGP/GPG key available at wwwkeys.us.pgp.net From effugas at best.com Thu Jun 24 09:54:54 1999 From: effugas at best.com (Dan Kaminsky) Date: Tue Dec 2 03:03:08 2003 Subject: /proc doesn't work with Samba Message-ID: <199906240954.CAA19392@shell3.ba.best.com> You can't share the proc file system in Samba. Can this be fixed? (OK, to clarify, you CAN share it, but the contents of each file are empty.) From jeannie at mitre.org Thu Jun 24 11:41:44 1999 From: jeannie at mitre.org (Jean Henchey) Date: Tue Dec 2 03:03:08 2003 Subject: drive mappings drop References: <199906240954.CAA19392@shell3.ba.best.com> Message-ID: <37721978.ABCCC101@mitre.org> I'm running solaris 2.6 and samba 2.0.0. My user base is mostly NT4. I have 1 volume in samba and about 30+ users connected to it at any time. (Though the number of people actively editing files is much lower.) For no apparent reason (ie nothing in the logfiles), users loose their identity in samba. They have already browsed the volume (ie authenticated to a PDC)..and when they go to edit, SWAT shows that the users are "nobody". They get the read-only view of the file space. They have to re-map the drive in order to get their identities back and write out files. I don't understand how samba could forget who the users are. Was there a bug in this version? I would appreciate any help and pointers. Jean -------------- next part -------------- A non-text attachment was scrubbed... Name: jeannie.vcf Type: text/x-vcard Size: 206 bytes Desc: Card for Jean Henchey Url : http://lists.samba.org/archive/samba-technical/attachments/19990624/6cbfbe6b/jeannie.vcf From jeannie at mitre.org Thu Jun 24 12:13:57 1999 From: jeannie at mitre.org (Jean Henchey) Date: Tue Dec 2 03:03:08 2003 Subject: drive mappings drop Message-ID: <37722105.6DBD94D1@mitre.org> (Take deux.) I'm running solaris 2.6 and samba 2.0.0. My user base is mostly NT4. I have 1 volume in samba and about 30+ users connected to it at any time. (Though the number of people actively editing files is much lower.) For reasons not recorded in the logfiles, users loose their identity in samba. They have already browsed the volume (ie authenticated to a PDC)..and when they go to edit, SWAT shows that the users are "nobody". They get the read-only view of the file space. They have to re-map the drive in order to get their identities back and write out files. I don't understand how samba could forget who the users are. Was there a bug in this version? I would appreciate any help and pointers. Jean -------------- next part -------------- A non-text attachment was scrubbed... Name: jeannie.vcf Type: text/x-vcard Size: 206 bytes Desc: Card for Jean Henchey Url : http://lists.samba.org/archive/samba-technical/attachments/19990624/d8d7a4f7/jeannie.vcf From jeannie at mitre.org Thu Jun 24 12:55:36 1999 From: jeannie at mitre.org (Jean Henchey) Date: Tue Dec 2 03:03:08 2003 Subject: drive mappings drop (Take trois.) Message-ID: <37722AC8.7FC59178@mitre.org> I'm running solaris 2.6 and samba 2.0.0. My user base is mostly NT4. I have 1 volume in samba and about 30+ users connected to it at any time. (Though the number of people actively editing files is much lower.) For reasons not recorded in the logfiles, users loose their identity in samba. They have already browsed the volume (ie authenticated to a PDC)..and when they go to edit, SWAT shows that the users are "nobody". They get the read-only view of the file space. They have to re-map the drive in order to get their identities back and write out files. I don't understand how samba could forget who the users are. Was there a bug in this version? I would appreciate any help and pointers. Jean p.s. My apologies to all for multiple messages that were blank. -------------- next part -------------- A non-text attachment was scrubbed... Name: jeannie.vcf Type: text/x-vcard Size: 206 bytes Desc: Card for Jean Henchey Url : http://lists.samba.org/archive/samba-technical/attachments/19990624/be8d5e07/jeannie.vcf From davecb at canada.sun.com Thu Jun 24 12:15:24 1999 From: davecb at canada.sun.com (David Collier-Brown) Date: Tue Dec 2 03:03:08 2003 Subject: Patch for slow smbclient performance References: Message-ID: <3772215C.8703DD95@canada.sun.com> James Turner wrote: > Below is a patch against samba 2.0.4b that adds a switch to > smbclient. I've found that using smbclient to access some Win95 > machines is incredibly slow -- 10k/second or worse. The problem > doesn't seem to occur when the access occur through smbd. Using > strace and gdb revealed the problem to be in the network read/write > size. This patch sets it ot be configurable via '-b'. > > Experimentation has shown some quite peculiar results. Basically the > breakpoint is around 1200 bytes for -b. Above it, and you get > 10k/sec. Below and you get 400-900k/sec(!). It's not a continuous > change; it's quite a jump for a change in one byte. I don't know what > value this might have for fixing the poor Win98 performance, but it > would seem that Win95 has problems with some patch sizes. Cool! In smbclient, this eventually changes the size of an fread on the socket... anyone have an idea why reducing from 65520 to 1200 would make a Poisonus Computer perform better? --dave -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | http://java.science.yorku.ca/~davecb Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb@canada.sun.com From f.stekelenburg at acriter.com Thu Jun 24 12:30:09 1999 From: f.stekelenburg at acriter.com (Frans Stekelenburg) Date: Tue Dec 2 03:03:08 2003 Subject: drive mappings drop (Take trois.) References: <37722AC8.7FC59178@mitre.org> Message-ID: <377224D1.777B985B@acriter.com> Obviously! :-) From mev0003 at unt.edu Thu Jun 24 12:33:54 1999 From: mev0003 at unt.edu (Matthew Vanecek) Date: Tue Dec 2 03:03:08 2003 Subject: 2.0.4b--I/O errors and other problems Message-ID: <377225B2.4AF34F6F@unt.edu> First off, I don't know if this is password caching revisited with a vengeance or what. It's very inconsistent for the amount of time the share will stay mounted. I *think* the following are the relevant messagess in the log: Jun 23 22:24:36 reliant kernel: smb_trans2_request: result=-32, setting invalid Jun 23 22:24:36 reliant kernel: smb_retry: caught signal And of course, I get the I/O error when trying to access the errant mount. Has anyone else experienced this problem with 2.0.4b? and how to fix it? And why smbumount won't work on these mounts, but I have to su to root to umount them? What would happen in a commercial setting, and the roots weren't available to umount the share? The command I use to mount the share is: smbmount //winnt/g$ XXXXXXXX -c 'mount mnts' and to unmount the share: su -c 'umount mnts' (most irritating--shouldn't have to be root to do that) Also, smbsh keeps seg faulting. I'm running RH 6.0 and kernel 2.2.10. I've got samba compiled, installed and running OK, as well as smbmount, but smbsh keeps crashing. As root, all it does is segfault. As a user, it segfaults and dumps core. The username/password don't seem to make a difference; I could type gibberish for all it matters. I actually installed samba to a sane location (/usr/local) instead of following Redhat's own unique file system standard. My smb.conf file has stayed the same, except for one little addition: "status=yes". This, it turns out, is another problem. Or is it a fix? 2.0.3 did not require this option, defaulting as it did to "status=yes" anyhow. Did this behavior change deliberately in 2.0.4b? STATUS..LCK refused to be created until I explicitly specified (what was supposed to be) the default setting of "status=yes" in smb.conf, which of course, caused smbstatus to not work right and generated a couple of other errors, which disappeared with the addition of that setting. -- Matthew Vanecek Course of Study: http://www.unt.edu/bcis Visit my Website at http://people.unt.edu/~mev0003 For answers type: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' ***************************************************************** For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something... From greg at discreet.com Thu Jun 24 12:42:22 1999 From: greg at discreet.com (Greg Dickie) Date: Tue Dec 2 03:03:08 2003 Subject: Patch for slow smbclient performance In-Reply-To: <3772215C.8703DD95@canada.sun.com> Message-ID: I must admit I havenot looked at the patch but is there any chance that its affecting the TCP window size? In a switched enviroment where there is no collision domain but there can be retransmissions, having a smaller window size could substantially affect how much data would be retransmitted for an error. Of course I would expect the change to be linear in that case.... Maybe Microsoft just did a really bad job when they "invented" MS TCP/IP ;-) Greg --------------------------------------------------------------------- Greg Dickie Just A Guy* *from discreet (the logic is gone) Montreal (514) 954-7171 greg@discreet.com On Thu, 24 Jun 1999, David Collier-Brown wrote: > James Turner wrote: > > Below is a patch against samba 2.0.4b that adds a switch to > > smbclient. I've found that using smbclient to access some Win95 > > machines is incredibly slow -- 10k/second or worse. The problem > > doesn't seem to occur when the access occur through smbd. Using > > strace and gdb revealed the problem to be in the network read/write > > size. This patch sets it ot be configurable via '-b'. > > > > Experimentation has shown some quite peculiar results. Basically the > > breakpoint is around 1200 bytes for -b. Above it, and you get > > 10k/sec. Below and you get 400-900k/sec(!). It's not a continuous > > change; it's quite a jump for a change in one byte. I don't know what > > value this might have for fixing the poor Win98 performance, but it > > would seem that Win95 has problems with some patch sizes. > > Cool! > In smbclient, this eventually changes the size of an fread on > the socket... anyone have an idea why reducing from 65520 > to 1200 would make a Poisonus Computer perform better? > > --dave > -- > David Collier-Brown, | Always do right. This will gratify some people > 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain > Willowdale, Ontario | http://java.science.yorku.ca/~davecb > Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb@canada.sun.com > From davecb at canada.sun.com Thu Jun 24 13:53:26 1999 From: davecb at canada.sun.com (David Collier-Brown) Date: Tue Dec 2 03:03:08 2003 Subject: Patch for slow smbclient performance References: Message-ID: <37723856.A1121E65@canada.sun.com> Jean Francois Micouleau spotted it: The packets were being fragmented and then reassembeled and the PC either was really slow doing so, or there were lost fragments, requiring the whole darn packet to be retransmitted, much as you suggested. Playing with socket options TCP_MSS and TCP_MAXGSEG might be the better way, according to Stevens. > Maybe Microsoft just did a really bad job when > they "invented" MS TCP/IP ;-) They sure didn't grok path MTU discovery! --dave -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | http://java.science.yorku.ca/~davecb Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb@canada.sun.com From Craig.Bridge at NSMG.Seagatesoftware.com Thu Jun 24 14:14:21 1999 From: Craig.Bridge at NSMG.Seagatesoftware.com (Craig Bridge) Date: Tue Dec 2 03:03:08 2003 Subject: FW: Patch for slow smbclient performance Message-ID: David Collier-Brown replied: > Cool! > In smbclient, this eventually changes the size of an fread on > the socket... anyone have an idea why reducing from 65520 > to 1200 would make a Poisonus Computer perform better? > > --dave > [Craig Bridge] Winsock client code splits large requests into smaller packets. Client "fairness" limits on how many outstanding packets prolong the acknowledgement of the last packet leaving the I/O request blocked. Single threaded user mode code will ping-pong between blocked on a large read and blocked on a large write. Two user-mode threads (a reader and a writer) allow read-ahead and socket transmission to overlap. My experience is the large negative "knee" in the performance curve is reduced and a more monotonic perfomance curve is obtained. Transfer sizes near low multiples the underlying blocking factors will still show up in the performance data. -Craig From timothy_d_cole at md.northgrum.com Thu Jun 24 15:52:02 1999 From: timothy_d_cole at md.northgrum.com (Cole, Timothy D.) Date: Tue Dec 2 03:03:08 2003 Subject: Patch for slow smbclient performance Message-ID: <51FBD4A8EFD9D111BA7300A0C927DADB56309D@xcgmd008.md.essd.northgrum.com> > -----Original Message----- > From: Craig Bridge [SMTP:Craig.Bridge@NSMG.Seagatesoftware.com] > Sent: Thursday, June 24, 1999 10:15 > To: Multiple recipients of list > Subject: FW: Patch for slow smbclient performance > > David Collier-Brown replied: > > Two user-mode threads (a reader and a writer) allow read-ahead > and socket transmission to overlap. My experience is the > large negative "knee" in the performance curve is reduced and a > more monotonic perfomance curve is obtained. Transfer sizes > near low multiples the underlying blocking factors will still show > up in the performance data. > I concur, but how portably can we do multithreaded code? Since not all the platforms Samba builds on support MT (or building with MT support is a royal pain; witness HP-UX), you'd really need to have a threaded and a non-threaded version.of the relevent code, if nothing else. Unless you can keep that split confined to a very small part of the code, it'll become an absolute bear to maintain. That being said, it still might be worth looking into. If I could get MT to work under HP-UX here, I might take a stab at implementing it myself, but so far no luck... From jallison at cthulhu.engr.sgi.com Thu Jun 24 16:43:19 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:08 2003 Subject: Patch for slow smbclient performance References: Message-ID: <37726027.ACFE5EA@engr.sgi.com> James Turner wrote: > > I sent this to the list a while back, but I don't think it made it > through for some reason, so here it is again. > > Below is a patch against samba 2.0.4b that adds a switch to > smbclient. I've found that using smbclient to access some Win95 > machines is incredibly slow -- 10k/second or worse. The problem > doesn't seem to occur when the access occur through smbd. Using > strace and gdb revealed the problem to be in the network read/write > size. This patch sets it ot be configurable via '-b'. > > Experimentation has shown some quite peculiar results. Basically the > breakpoint is around 1200 bytes for -b. Above it, and you get > 10k/sec. Below and you get 400-900k/sec(!). It's not a continuous > change; it's quite a jump for a change in one byte. I don't know what > value this might have for fixing the poor Win98 performance, but it > would seem that Win95 has problems with some patch sizes. > > Without further adieu, the patch. Good work, thanks. I'll put it into 2.0.5. Cheers, Jeremy. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From lkcl at switchboard.net Thu Jun 24 17:38:33 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:09 2003 Subject: Patch for slow smbclient performance In-Reply-To: <51FBD4A8EFD9D111BA7300A0C927DADB56309D@xcgmd008.md.essd.northgrum.com> Message-ID: > I concur, but how portably can we do multithreaded code? Since not see samba archives from two and years ago. short answer: no, samba will not be multithreaded, not by any of the current team members. luke From skeet at Bridgewater.EDU Thu Jun 24 20:04:12 1999 From: skeet at Bridgewater.EDU (Douglas K. Fischer) Date: Tue Dec 2 03:03:09 2003 Subject: 2.0.4b - Bug in dfree > 2GB reporting for 16-bit clients Message-ID: In 2.0.4b using a 16-bit client (in this case Lanman for DOS), disk space reporting for partitions greater than 2GB always reports 0 space free. I've tracked this down to the disk_norm routine in the smbd/dfree.c file. In the code for adjusting block size and disk size/free values for 16-bit reporting, WORDMAX was incorrectly being multiplied by 512 before being compared with bsize. This resulted in the offending values not being truncated to fit into 16-bit fields. I've included a patch below to fix this: ----- begin dfree.c.patch ----- *** smbd/dfree.c.orig Mon Feb 1 18:37:33 1999 --- smbd/dfree.c Thu Jun 24 14:54:47 1999 *************** *** 48,55 **** /* * Force max to fit in 16 bit fields. */ ! if (*bsize > (WORDMAX*512)) { ! *bsize = (WORDMAX*512); if (*dsize > WORDMAX) *dsize = WORDMAX; if (*dfree > WORDMAX) --- 48,55 ---- /* * Force max to fit in 16 bit fields. */ ! if (*bsize > (WORDMAX)) { ! *bsize = (WORDMAX); if (*dsize > WORDMAX) *dsize = WORDMAX; if (*dfree > WORDMAX) ----- end dfree.c.patch ----- Douglas ---------------------------------------------------------------------- Douglas K. Fischer DFischer@Bridgewater.EDU (540) 828 - 5343 Network Systems Engineer Information Technology Center College Box 36 Bridgewater College Bridgewater, VA 22812 Internet: http://www.bridgewater.edu/~dfischer FAX: (540) 828 - 5493 ---------------------------------------------------------------------- From effugas at best.com Thu Jun 24 20:54:14 1999 From: effugas at best.com (Dan Kaminsky) Date: Tue Dec 2 03:03:09 2003 Subject: /proc doesn't work with Samba In-Reply-To: from Robert Sandilands at "Jun 24, 99 04:01:27 pm" Message-ID: <199906242054.NAA02291@shell3.ba.best.com> > > On Thu, 24 Jun 1999, Dan Kaminsky wrote: > > > You can't share the proc file system in Samba. Can this be fixed? > > > > It is totally correct... /proc is not quite a standard file system. Some > serious security implications exist if you could share it. Like if you could share /etc? Oh wait, you can :-) > All the files in /proc is "special" files something like devices in /dev > and this is local to the machine and also contains "priviledged" > information about the machine. It should not be shared and if shared it > should not allow you to get to the contents of those files. It's not the place of the file sharing architecture to define which files are "too important" to allow remote access to. Is /proc a serious security risk if the nobody user can read it? I mean, there's no reason that you can't set the access user on the /proc share to "nobody". From cartegw at Eng.Auburn.EDU Thu Jun 24 21:04:00 1999 From: cartegw at Eng.Auburn.EDU (Gerald Carter) Date: Tue Dec 2 03:03:09 2003 Subject: /proc doesn't work with Samba References: <199906242054.NAA02291@shell3.ba.best.com> Message-ID: <37729D40.AACAD6D4@eng.auburn.edu> Dan Kaminsky wrote: > > It's not the place of the file sharing architecture > to define which files are "too important" to allow > remote access to. Is /proc a serious security risk if > the nobody user can read it? I mean, there's no reason > that you can't set the access user on the /proc share > to "nobody". Maybe I missed something here and so I've got to ask... **Why in the world would you want to share /proc??? jerry ________________________________________________________________________ Gerald ( Jerry ) Carter Engineering Network Services Auburn University jerry@eng.auburn.edu http://www.eng.auburn.edu/users/cartegw "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" ( 1979 ) From timothy_d_cole at md.northgrum.com Thu Jun 24 21:44:22 1999 From: timothy_d_cole at md.northgrum.com (Cole, Timothy D.) Date: Tue Dec 2 03:03:09 2003 Subject: /proc doesn't work with Samba Message-ID: <51FBD4A8EFD9D111BA7300A0C927DADB5630A1@xcgmd008.md.essd.northgrum.com> > -----Original Message----- > From: Gerald Carter [SMTP:cartegw@Eng.Auburn.EDU] > Sent: Thursday, June 24, 1999 17:05 > To: Multiple recipients of list > Subject: Re: /proc doesn't work with Samba > > Dan Kaminsky wrote: > > > > It's not the place of the file sharing architecture > > to define which files are "too important" to allow > > remote access to. Is /proc a serious security risk if > > the nobody user can read it? I mean, there's no reason > > that you can't set the access user on the /proc share > > to "nobody". > > Maybe I missed something here and so I've got to ask... > > > **Why in the world would you want to share /proc??? > I suspect it's being shared as part of a share exporting the root directory. I usually use "dont descend" in these cases, anyway (i.e. for /dev and /proc). There are more convenience/saftey issues than there are security issues, really: You generally don't want to be exporting /dev, as a user poking around in Windows Explorer who happens, for instance, to have read access to an auto-rewind tape device (i.e. they're some sort of demi-admin on the Unix side) could end up suprising someone else when the tape drive tries to rewind as the poor sap is in the middle of loading it... /dev, especially in the Land of Big Iron, has just a little too much influence on the Real World to be casually poked from Explorer. I imagine opening /dev/zero in a text editor might yield some interesting effects in your network, too. /proc can do some funky things to Explorer, too, if it tries to recurse into it to compute directory sizes; think infinite recursion. (note for dont descend; for a root directory share, omit the leading slashes) From lkcl at switchboard.net Thu Jun 24 21:52:32 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:09 2003 Subject: /proc doesn't work with Samba In-Reply-To: <51FBD4A8EFD9D111BA7300A0C927DADB5630A1@xcgmd008.md.essd.northgrum.com> Message-ID: > /proc can do some funky things to Explorer, too, if it tries to > recurse into it to compute directory sizes; think infinite recursion. hmmm... is there a /proc/reboot? :-) can this be activated by doing a "stat()"? From effugas at best.com Thu Jun 24 22:04:40 1999 From: effugas at best.com (Dan Kaminsky) Date: Tue Dec 2 03:03:09 2003 Subject: /proc doesn't work with Samba In-Reply-To: <51FBD4A8EFD9D111BA7300A0C927DADB5630A1@xcgmd008.md.essd.northgrum.com> from "Cole, Timothy D." at "Jun 25, 99 07:45:24 am" Message-ID: <199906242204.PAA14394@shell3.ba.best.com> > > **Why in the world would you want to share /proc??? > > > I suspect it's being shared as part of a share exporting the root > directory. I usually use "dont descend" in these cases, anyway (i.e. for > /dev and /proc). There are more convenience/saftey issues than there are > security issues, really: No, actually I explicitly *want* remote access to /proc. NT can get remote performance metrics from other NT machines; /proc is a cheap and *easy* way to get remote performance metrics from Unix machines for a 95/98/NT box. > You generally don't want to be exporting /dev, as > user poking > around in Windows Explorer who happens, for instance, to have read access to > an auto-rewind tape device (i.e. they're some sort of demi-admin on the Unix > side) could end up suprising someone else when the tape drive tries to > rewind as the poor sap is in the middle of loading it... /dev, especially in > the Land of Big Iron, has just a little too much influence on the Real World > to be casually poked from Explorer. I imagine opening /dev/zero in a text > editor might yield some interesting effects in your network, too. If an Average User can break a tape drive, that's the fault of the Unix Security Architecture. I mean, you don't blame vi if /etc/passwd is fully modifiable. > /proc can do some funky things to Explorer, too, if it tries to > recurse into it to compute directory sizes; think infinite recursion. ls -R doesn't fail. Neither does du, though I assume for different reasons. Something like a "limit infinite recurse" parameter might help. > (note for dont descend; for a root directory share, omit the leading > slashes) > > From ldx at ibm.net Thu Jun 24 23:19:43 1999 From: ldx at ibm.net (Doug VanLeuven) Date: Tue Dec 2 03:03:09 2003 Subject: string overflow error & patch Message-ID: <3772BD0F.1CDECEA9@ibm.net> Redhat 5.2, kernel 2.0.36, gcc 2.7.2.3-14, CVS 6-17-99 Original error: ERROR: string overflow by 7 in safe_strcpy [michaele] line: 'users::1401:,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,,,keng' group name users members: 292 Item 1: make_group_line was failing to increment the pointer after copiying each group name, only the commas Item 2: make_group_line failed to cease trying to copying names when the PSTRING_LEN limit was reached allowing the max_len counter to go negative. Item 3: safe_strcpy ignores the negative and would have corrupted memory if make_group_line had actually been incrementing for the names. Item 4: groupdb/aliasdb.c, groupdb/builtindb.c, groupdb/groupdb.c were all coded the same way, so the patch nees to be applied to all three. This is a minor error I don't know exactly what this would have broken, but it seems it should be fixed. Anyone trying to have groups with many members might be interested. Please check my work. =================================================================== RCS file: /cvsroot/samba/source/groupdb/aliasdb.c,v retrieving revision 1.7 diff -u -r1.7 aliasdb.c --- aliasdb.c 1998/12/07 17:23:46 1.7 +++ aliasdb.c 1999/06/24 22:37:21 @@ -474,14 +474,15 @@ for (i = 0; i < (*num_mem); i++) { len = strlen((*mem)[i].name); - p = safe_strcpy(p, (*mem)[i].name, max_len); - - if (p == NULL) - { + if (len < max_len) { + p = safe_strcpy(p, (*mem)[i].name, max_len); + } + else { DEBUG(0, ("make_alias_line: out of space for aliases!\n")); return False; } + p += len; max_len -= len; if (i != (*num_mem)-1) Index: groupdb/builtindb.c =================================================================== RCS file: /cvsroot/samba/source/groupdb/builtindb.c,v retrieving revision 1.2 diff -u -r1.2 builtindb.c --- builtindb.c 1998/12/07 17:23:46 1.2 +++ builtindb.c 1999/06/24 22:37:22 @@ -453,14 +453,15 @@ for (i = 0; i < (*num_mem); i++) { len = strlen((*mem)[i].name); - p = safe_strcpy(p, (*mem)[i].name, max_len); - - if (p == NULL) - { + if (len < max_len) { + p = safe_strcpy(p, (*mem)[i].name, max_len); + } + else { DEBUG(0, ("make_builtin_line: out of space for builtin aliases!\n")); return False; } + p += len; max_len -= len; if (i != (*num_mem)-1) Index: groupdb/groupdb.c =================================================================== RCS file: /cvsroot/samba/source/groupdb/groupdb.c,v retrieving revision 1.5 diff -u -r1.5 groupdb.c --- groupdb.c 1998/12/07 17:23:46 1.5 +++ groupdb.c 1999/06/24 22:37:22 @@ -472,14 +472,15 @@ for (i = 0; i < (*num_mem); i++) { len = strlen((*mem)[i].name); - p = safe_strcpy(p, (*mem)[i].name, max_len); - - if (p == NULL) - { + if (len < max_len) { + p = safe_strcpy(p, (*mem)[i].name, max_len); + } + else { DEBUG(0, ("make_group_line: out of space for groups!\n")); return False; } + p += len; max_len -= len; if (i != (*num_mem)-1) =================================================================== -- Doug VanLeuven - 707-545-6933 (voice) 707-545-6945 (fax) Chief Engineer, USMM roamdad@ibm.net Programmer/Analyst, SCWA doug@scwa.ca.gov From simonmu at optimation.co.nz Fri Jun 25 04:09:21 1999 From: simonmu at optimation.co.nz (Simon Murcott) Date: Tue Dec 2 03:03:09 2003 Subject: Windows 95 Oddities Message-ID: Hi People, I am seeing some rather odd behaviour on our network using samba 2.0.4b as a PDC and Windows 95 clients doing domain logins (yeah right ... I know). Anyway, after doing a sucessful authentication the client then runs a kix32 script which tries to find who the logon server is. From what I can see the script is doing a win32 call to find this information. This call results in a named pipe which one can see from the log. What the server returns is incorrect (it is actually another samba server across the wan but still on our network). I am having difficulty decyphering the log file to work out what is actually going on. If anyone could give me some pointers to sort this out it would help. Here is a debug level 10 of the relevant bits: [1999/06/25 15:27:30, 10] lib/util.c:dump_data(2832) [000] 5C 50 49 50 45 5C 4C 41 4E 4D 41 4E 00 68 00 57 \PIPE\LA NMAN.h.W [1999/06/25 15:27:30, 10] lib/util.c:dump_data(2840) [010] 72 4C 65 68 44 4F 00 42 31 36 00 00 00 14 00 18 rLehDO.B 16...... [1999/06/25 15:27:30, 10] lib/util.c:dump_data(2840) [020] 00 00 00 ... [1999/06/25 15:27:30, 3] smbd/process.c:switch_message(448) switch message SMBtrans (pid 1088) [1999/06/25 15:27:30, 5] smbd/uid.c:become_user(262) become_user uid=(0,60001) gid=(0,60001) [1999/06/25 15:27:30, 3] lib/doscalls.c:dos_ChDir(336) dos_ChDir to /tmp [1999/06/25 15:27:30, 3] smbd/ipc.c:reply_trans(3612) trans <\PIPE\LANMAN> data=0 params=22 setup=0 [1999/06/25 15:27:30, 5] smbd/ipc.c:reply_trans(3623) calling named_pipe [1999/06/25 15:27:30, 3] smbd/ipc.c:named_pipe(3469) named pipe command on name [1999/06/25 15:27:30, 3] smbd/ipc.c:api_reply(3414) Got API command 104 of form (tdscnt=0,tpscnt=22,mdrcnt=20,mprc nt=8) [1999/06/25 15:27:30, 3] smbd/ipc.c:api_reply(3418) Doing NetServerEnum Regards Simon Murcott A closed mouth gathers no foot. From fgouget at psn.net Fri Jun 25 05:34:44 1999 From: fgouget at psn.net (Francois Gouget) Date: Tue Dec 2 03:03:09 2003 Subject: Short (MS-DOS) names compatibility with NT In-Reply-To: <003501bebd83$f1ae4cd0$21c9ca95@mow.siemens.ru> Message-ID: On Thu, 24 Jun 1999, Andrej Borsenkow wrote: > It may be not a problem, but if I remember it correctly, SAMBA should build the > short names the same as NT This is unfortunately impossible to do without cooperation from the underlying Unix filesystem. NT stores both the long and the short name on the filesystem be it VFAT or NTFS. Unix filesystems do not make any provision for storing a short name so Samba has to dynamically generate a short name that fits the bill. I only see two alternatives to the current solution: - modify the Unix filesystem (ext2fs, ffs, the solaris filesystem, ...) so that we can store a short name. This is both practically unfeasible and unacceptable. - use a technique 'a la' UMSDOS, i.e. store the association between the long and the short name in a per directory file. Performance would certainly suffer but it would be feasible as UMSDOS demonstrates it (UMSDOS solves the opposite problem: i.e. storing Unix specific information, including long names, on a filesystem that supports neither). [...] > is Explorer context menu, the MS-DOS name is shown by NT as > > 49A6E~1.0-R > > and by SAMBA as > > 4~%E.0-R This is a bit strange for a short name: it is too short, the part before the '.' should have 8 characters. If this is really the name you got it should probably be investigated. -- Francois Gouget fgouget@multimania.com http://www.multimania.com/fgouget In a world without fences who needs Gates? From davecb at canada.sun.com Fri Jun 25 11:33:09 1999 From: davecb at canada.sun.com (David Collier-Brown) Date: Tue Dec 2 03:03:09 2003 Subject: /proc doesn't work with Samba References: <199906242054.NAA02291@shell3.ba.best.com> <37729D40.AACAD6D4@eng.auburn.edu> Message-ID: <377368F5.994CFD0B@canada.sun.com> Gerald Carter wrote: > **Why in the world would you want to share /proc??? Probably did so by accident, but I wouldn't mind running a remote monitoring program on Linux via an ordinary filesystem mount (;-)) --dave (who's now in the performance group at work) c-b -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | http://java.science.yorku.ca/~davecb Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb@canada.sun.com From James_Mathiesen at ml.com Fri Jun 25 13:57:55 1999 From: James_Mathiesen at ml.com (James Mathiesen) Date: Tue Dec 2 03:03:09 2003 Subject: WARNING: dfree is broken on this system Message-ID: <199906251357.JAA27500@sys1.des.jhy.us.ml.com> I'm running Samba 2.0.4b on Solaris for quite some time. For as long as I can remember I've been getting hundreds of messages like this per day: WARNING: dfree is broken on this system I finally got around to tracking down the cause. The message is generated in disk_free() when fsusage() indicates that the size of the underlying filesystem is zero blocks. Well, I also have am-utils installed. The amd mount points look like this: f_bsize 1024 f_frsize 1024 f_blocks 0 f_bfree 0 f_bavail 0 f_files 4294967295 f_ffree 4294967295 f_favail 4294967295 f_fsid 51118081 f_basetype 'nfs' f_flag 0 f_namemax 4294967295 f_fstr '' So there's at least one example of the total number of blocks on a filesystem validly being zero. Attached is the patch I made, which adds to the statvfs version of the code a check to set the size of the filesystem to 20MB if it happens to be zero -- ie assume that statvfs will never succeed and return incorrect information. I haven't really convinced myself that this is the correct solution. Maybe it would be better to raise warnings in this area iff underlying systems calls have failed -- otherwise take the returned data as gospel and massage only as necessary to meet CIFS semantics. james Index: dfree.c =================================================================== RCS file: /src/local/repository/usr/local/pkg/samba/source/smbd/dfree.c,v retrieving revision 1.1.1.2 retrieving revision 1.3 diff -u -r1.1.1.2 -r1.3 --- dfree.c 1999/03/09 19:25:04 1.1.1.2 +++ dfree.c 1999/06/25 13:46:33 1.3 @@ -162,15 +162,32 @@ adjust_blocks ((SMB_BIG_UINT)(B), fsd.f_frsize ? (SMB_BIG_UINT)fsd.f_frsize : (SMB_BIG_UINT)fsd.f_bsize, (SMB_BIG_UINT)512) #ifdef STAT_STATVFS64 - struct statvfs64 fsd; - if (statvfs64(path, &fsd) < 0) return -1; +# define STATVFS statvfs64 #else - struct statvfs fsd; - if (statvfs(path, &fsd) < 0) return -1; +# define STATVFS statvfs #endif + struct STATVFS fsd; + if ( STATVFS(path, &fsd) < 0 ) return -1; + + /* + ** amd from am-utils typically returns + ** + ** f_blocks == f_bfree == f_bavail == 0 + ** + ** on automount points. This gets flagged as sign of a broken + ** dfree implementation in disk_free, but in this case it isn't. + ** So if we notice we have a zero size filesystem, pretend it + ** is 20MB. + */ + if ( fsd.f_blocks == 0 ) { + fsd.f_bsize = fsd.f_frsize = 1024; + fsd.f_blocks = 20*1024; + } + /* f_frsize isn't guaranteed to be supported. */ +# undef STATVFS #endif /* STAT_STATVFS */ #ifndef CONVERT_BLOCKS From timothy_d_cole at md.northgrum.com Fri Jun 25 14:00:17 1999 From: timothy_d_cole at md.northgrum.com (Cole, Timothy D.) Date: Tue Dec 2 03:03:09 2003 Subject: /proc doesn't work with Samba Message-ID: <51FBD4A8EFD9D111BA7300A0C927DADB5630A2@xcgmd008.md.essd.northgrum.com> > -----Original Message----- > From: Dan Kaminsky [SMTP:effugas@best.com] > Sent: Thursday, June 24, 1999 18:05 > To: timothy_d_cole@md.northgrum.com > Cc: samba-technical@samba.org > Subject: Re: /proc doesn't work with Samba > > > > **Why in the world would you want to share /proc??? > > > > > I suspect it's being shared as part of a share exporting the root > > directory. I usually use "dont descend" in these cases, anyway (i.e. > for > > /dev and /proc). There are more convenience/saftey issues than there > are > > security issues, really: > > No, actually I explicitly *want* remote access to /proc. NT can get > remote performance metrics from other NT machines; /proc is a cheap and > *easy* way to get remote performance metrics from Unix machines for a > 95/98/NT box. > > > You generally don't want to be exporting /dev, as > > user poking > > around in Windows Explorer who happens, for instance, to have read > access to > > an auto-rewind tape device (i.e. they're some sort of demi-admin on the > Unix > > side) could end up suprising someone else when the tape drive tries to > > rewind as the poor sap is in the middle of loading it... /dev, > especially in > > the Land of Big Iron, has just a little too much influence on the Real > World > > to be casually poked from Explorer. I imagine opening /dev/zero in a > text > > editor might yield some interesting effects in your network, too. > > If an Average User can break a tape drive, > Well, not an _average_ user. It'd have to be someone who has business with the tape drive. Hopefully they'd normally be in communication with the folks loading the tape, but that doesn't preclude stupid mistakes when they're poking around in Explorer one day. And I was thinking more along the lines of damaging the tape and/or the hapless operator's fingers. The tape drive itself should be safe enough. Like I said, convenience/saftey, more than security. > that's the fault of the Unix > Security Architecture. > More like the fault of the sysadmin, if an _average_ user can do that. > I mean, you don't blame vi if /etc/passwd is fully > modifiable. > Nor do you blame the Unix Security Architecture :P > > /proc can do some funky things to Explorer, too, if it tries to > > recurse into it to compute directory sizes; think infinite recursion. > > ls -R doesn't fail. Neither does du, though I assume for different > reasons. > No, same reason in fact. "ls -R" doesn't follow symlinks down in the tree, nor does straight "du". Explorer via Samba, however, will. The /proc//cwd entries can be the biggest culprit, if you have any processes with a cwd in the root dir or /proc (i.e. your smbd process) > Something like a "limit infinite recurse" parameter might help. > enh; maybe "recursion limit" would be a better name. That might actually be nice to have for other reasons, too, so long as nothing else was hurt by implementing it. All this being said, you do have a really good reason to export /proc ... I can't offhand think of a way to make dont descend apply to all the /proc/ directories, though. I imagine you're interested in /proc/interrupts and some other things out at the top level of /proc, or I'd suggest you just export a subtree. Since you're probably just doing this for your own use, none of the /proc problems I mentioned before is really a very serious issue, but it would be nice to be able to fix them even so. And there _is_ still the issue of Samba not behaving quite the way you'd want for files that stat() reports as being 0 bytes in length. Hrm... From lkcl at switchboard.net Fri Jun 25 16:42:15 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:09 2003 Subject: Problems with smbpasswd In-Reply-To: <005a01bebea5$d039c200$63150359@moj.wa.gov.au> Message-ID: On Fri, 25 Jun 1999, Nick Tan wrote: > Sorry, should have included this in my first message. BTW, I had samba yes :-) > os level = 1 just for your own browsing peace of mind, set this to 33. > ;*******************section netlogon***************** > [netlogon] > comment = Network Logon Service > path = /home/netlogon > guest ok = yes > writable = no > share modes = no guest access should be denied to this share. *sigh*, ok: there's nothing obvious. does smbpasswd work on loopback (on local machine)? does it fail as ordinary user or as root? does it work on the first user in your smbpasswd file? please try and track this down a bit more for me. with three users in my smb.conf file and... *oh*, i commented out the hashed_getpwnam() code, you might want to try the latest cvs. if anyone wants to continue to use that (because you have hundreds of users and groups) then #define USE_HASHED_PWNAM in Makefile or lib/username.c. luke From lkcl at switchboard.net Fri Jun 25 16:53:56 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:09 2003 Subject: Windows 95 Oddities In-Reply-To: Message-ID: On Fri, 25 Jun 1999, Simon Murcott wrote: > Hi People, > > I am seeing some rather odd behaviour on our network using samba 2.0.4b as a PDC > and Windows 95 clients doing domain logins (yeah right ... I know). > > Anyway, after doing a sucessful authentication the client then runs a kix32 > script which tries to find who the logon server is. From what I can see the > script is doing a win32 call to find this information. ah. it may be an unsupported NetServerEnum2 call. can you get a Netmon trace of this kix32 behaviour against an nt PDC? From lkcl at switchboard.net Fri Jun 25 17:09:22 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:09 2003 Subject: cached password #ifdef'd out by default. In-Reply-To: <19990625174738.36329@maunsell.co.uk> Message-ID: On Sat, 26 Jun 1999, Andy Smith wrote: > > (because you have hundreds of users and groups) then #define > > USE_HASHED_PWNAM in Makefile or lib/username.c. > > logins failed completely for me if I didn't include it back in as above. yes, probably because the cache saves you massive amounts of time! From sharpe at ns.aus.com Sat Jun 26 00:14:07 1999 From: sharpe at ns.aus.com (Richard Sharpe) Date: Tue Dec 2 03:03:09 2003 Subject: Latest NT vs Linux benchmark Message-ID: <3.0.5.32.19990626091407.00795490@mail.adelaide.on.net> http://www.zdnet.com/pcweek/stories/news/0,4153,1015266,00.html Regards ------- Richard Sharpe, sharpe@ns.aus.com, NS Computer Software and Services P/L, Samba (Team member www.samba.org), Ethereal (Team member www.zing.org) Co-author, SAMS Teach Yourself Samba in 24 Hours From soporte at sentinel.com.ar Sat Jun 26 06:23:42 1999 From: soporte at sentinel.com.ar (Hernan Ochoa) Date: Tue Dec 2 03:03:09 2003 Subject: some questions about loggin on and MS RPCs Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, i have a couple of questions i've been reading a lot of things, samba source code, cifs6.txt, cifsntdomain.txt, cifsrap2.txt and more but i have some doubts. what is actually a domain logon?. i'm at my nt workstation, i want to logon to my PDC. i issue my user, password, and then what happens? i connect to NETLOGON, i establish a secure channel using my machine trust account and generating the SKey. now i issue a SAM_LOGON, if i'm doing an interactive logon, i send the LM/NT hashes. if everything was ok, so, right, i could log on?. and now what? a SAM_LOGOFF is done? and the connection with the PDC is broken?. or what? now, if i issue a net use x: \\MYSERVER\C$ this is done using a new SMB connection or the previous logon connection is used? (MYSERVER is the name of my PDC). and what, the PDC redirector's service remembers my credentials and based on that it decides if i can access the C$ share???. and picture this situation. i'am on my nt workstation, i'm not part of any domain. i log on locally to the nt workstation, as administrator passwd: foo ok, no, i do this usrmgr \\MYSERVER and the thing is, the account administrator at MYSERVER has the same password (foo) as in my workstation, so, now do anything i want with the users of that domain. ok, why is that??????. there's something about the authentication method of RPC and PIPE that i don't understand. i do a sessionsetup anonymously, i do a tree connect anonymously to IPC$/IPC, annd then i do a SMB_TRANSACT to \\PIPE\LSARPC for example, ok, where did the authentacion occurred?????????? all the conections where anonymous. that's the thing i'm missing, and i can't seem to find. thanks in advance. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQA/AwUBN3Rj5YUFmApOzIXUEQImYACcCoVxQDWtSdizP8ahdBUwDa8TjxcAn1CH YbwZVzFqxvEiFPm1OQYP025N =IRe4 -----END PGP SIGNATURE----- From beef at cybertouch.org Sun Jun 27 15:13:47 1999 From: beef at cybertouch.org (Lanny Baron) Date: Tue Dec 2 03:03:09 2003 Subject: passwd's and access to shares Message-ID: <000001bec0af$a884fc50$0302b7d8@cybertouch.org> Hello everyone, Last night for an experiment I changed my passwd on my FreeBSD/Samba server and left my passwd as it was originally on my NT box. Immediatley after changing my passwd, I was still able to access all the shares. However, this morning I cannot. It makes complete sense to me that I am unable to access any shares with a different passwd on the FreeBSD/Samba server than on the NT box (same username). But it does not make sense that I was able to access the shares right after changing the passwd. So here is the question. Is there a certain amount of time needed so that any change in passwd's will prevent a user from accessing the shares? It seems like the passwd mechanisms on both machines talk to each other...just that they take their sweet time about it. Thanks and have a great day :-) Lanny From robert at vps.co.za Mon Jun 28 08:47:11 1999 From: robert at vps.co.za (Robert Sandilands) Date: Tue Dec 2 03:03:09 2003 Subject: Latest NT vs Linux benchmark In-Reply-To: <3.0.5.32.19990626091407.00795490@mail.adelaide.on.net> Message-ID: On Sat, 26 Jun 1999, Richard Sharpe wrote: > http://www.zdnet.com/pcweek/stories/news/0,4153,1015266,00.html This is similar to test results I got in my limited testing of Samba off real world work. Using the same hardware we compiled, using several different compilers, our software on a Microsoft NT server in 25 min and on a RedHat 5.2 + Samba 2.0.3 in 47 min. This is mostly C++ compilers for Dos, Windows 9x, NT, Novell OS targets and more than 150,000 lines of code distributed over approx. 1,300 c++ files. For porting reasons we are staying with Samba... The fact that it is also more stable helps a bit :-) But if anybody is going to work on improving these benchmarks I would like to help if help is needed. _________________________________________________________________________ Silly little things like representing anybody else is not of importance ------------------------------------------------------------------------- Robert Sandilands - Peace is when the music of the soul harmonizes with the music of Life Tel: +27-12-841-2106, Fax: +27-12-841-4670, Email: robert@vps.co.za ------------------------------------------------------------------------- From tridge at samba.org Mon Jun 28 09:01:47 1999 From: tridge at samba.org (Andrew Tridgell) Date: Tue Dec 2 03:03:09 2003 Subject: Latest NT vs Linux benchmark In-Reply-To: (message from Robert Sandilands on Mon, 28 Jun 1999 18:45:05 +1000) References: Message-ID: <19990628090154Z12667840-13565+5014@samba.anu.edu.au> > But if anybody is going to work on improving these benchmarks I would like > to help if help is needed. if you want to look at it then see ftp://samba.org/pub/tridge/dbench/README Cheers, Tridge From sharpe at ns.aus.com Mon Jun 28 11:47:32 1999 From: sharpe at ns.aus.com (Richard Sharpe) Date: Tue Dec 2 03:03:09 2003 Subject: passwd's and access to shares In-Reply-To: <000001bec0af$a884fc50$0302b7d8@cybertouch.org> Message-ID: <3.0.5.32.19990628204732.0092c2c0@mail.adelaide.on.net> Hi, At 01:15 AM 6/28/99 +1000, beef@cybertouch.org wrote: >Hello everyone, > >Last night for an experiment I changed my passwd on my FreeBSD/Samba server >and left my passwd as it was originally on my NT box. Immediatley after >changing my passwd, I was still able to access all the shares. However, this >morning I cannot. Hmmm, did you try to access a new share? Ie, with a net/use or anything like that? Any shares that were already being accessed on an existing connection would still be accessible, because the Username/password thingt happened when you first logged on. If you changed your password on the Samba box, then this would not have much impact, unless you tried to access the Samba box from another client with the old password. It is kinda like logging on, then changing your password. You do not get kicked off. However, when you log back on, you will not be able to use the old password to log on again. >It makes complete sense to me that I am unable to access any shares with a >different passwd on the FreeBSD/Samba server than on the NT box (same >username). But it does not make sense that I was able to access the shares >right after changing the passwd. > >So here is the question. Is there a certain amount of time needed so that >any change in passwd's will prevent a user from accessing the shares? It >seems like the passwd mechanisms on both machines talk to each other...just >that they take their sweet time about it. > >Thanks and have a great day :-) > >Lanny > > Regards ------- Richard Sharpe, sharpe@ns.aus.com, NS Computer Software and Services P/L, Samba (Team member www.samba.org), Ethereal (Team member www.zing.org) Co-author, SAMS Teach Yourself Samba in 24 Hours From Peter.Polkinghorne at brunel.ac.uk Mon Jun 28 11:50:43 1999 From: Peter.Polkinghorne at brunel.ac.uk (Peter Polkinghorne) Date: Tue Dec 2 03:03:09 2003 Subject: Samba: Applied in the Large Message-ID: <2125.199906281250@moomin.brunel.ac.uk> This is the slightly pretentious title to a talk, I gave on 28 June 1999 to the UKUUG Linux Conference. As many of you may not have been able to go, I have put up the slides & paper, plus raw data on the Web: http://www.brunel.ac.uk/%7Epeter/samba/ (the %7E is a tilde ~ ). This is based on the article I posted to the mailing lists entitled: Samba Load Testing at Brunel University Hope this helps someone ... -- ----------------------------------------------------------------------------- | Peter Polkinghorne, Computer Centre, Brunel University, Uxbridge, UB8 3PH,| | Peter.Polkinghorne@brunel.ac.uk +44 1895 274000 x2561 UK | ----------------------------------------------------------------------------- From soporte at sentinel.com.ar Mon Jun 28 14:13:28 1999 From: soporte at sentinel.com.ar (Hernan Ochoa) Date: Tue Dec 2 03:03:09 2003 Subject: RPC auth Message-ID: hi. well, i think i found it. in rpc_client/cli_pipe.c in function create_rpc_bind_resp() there the NT/LM hashes are sent. it says something about a 3-way handshake, and in the same file i guess the RPC is negotiating the SSP (Security Service Provider) to use, and i think samba is selecting NTLM, the default. everything is fitting now, i think. is there any documentation about this? i mean, something written by the samba team? apart from cifsntdomain.txt? well, i'll keep reading the code. But there's still one thing i like to know, i'll do some tests, but maybe some of you already did. what is a domain logon? a connection to NETLOGON, creating the secure channel using the machine trust account, and then issuing a SAM_LOGON, and here you can choose between an interactive logon or a network logon, in the interactive logon the NT/LM hashes are sent encrypted by the Skey, in the network logon the challenge-response method is sued right? and nt workstation uses the interactive logon type when a user tries to logon to a PDC using the normal winlogon/msgina interface right? but then, once i'm logged on, if i do something like net use x: \\MYPDC\c$ NT uses the same TCP:139 connection to access this share, but it issues a new sessetion setup using my credentials, but all this data, and subsequents SMB_OPEN and stuf fover that tree connect aren't encrypted using the Skey, is that right? well, again, i'll do some tests to verify this, but if someone already knows this, i'll be glad (very glad :)) to hear your experience. thanks in advance. bye From timothy_d_cole at md.northgrum.com Mon Jun 28 15:35:11 1999 From: timothy_d_cole at md.northgrum.com (Cole, Timothy D.) Date: Tue Dec 2 03:03:09 2003 Subject: ./configure Message-ID: <51FBD4A8EFD9D111BA7300A0C927DADB5630A9@xcgmd008.md.essd.northgrum.com> > Hrm. The "testing for fcntl locking..." test seems to hang most of the > time for me. I can usually get it to make it through at least once, but > lately I've had no success at all. This is under HP-UX 10.20. Has anyone > else experienced similar problems? From jallison at cthulhu.engr.sgi.com Mon Jun 28 17:00:43 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:09 2003 Subject: Latest NT vs Linux benchmark References: Message-ID: <3777AA3B.DAC14ABF@engr.sgi.com> Robert Sandilands wrote: > Using the same hardware we compiled, using several different compilers, > our software on a Microsoft NT server in 25 min and on a RedHat 5.2 + > Samba 2.0.3 in 47 min. This is mostly C++ compilers for Dos, Windows 9x, > NT, Novell OS targets and more than 150,000 lines of code distributed over > approx. 1,300 c++ files. The level II oplock (read-only oplocks) code that's gone into what will become 2.0.5 should help this quite a bit (if it is being concurrently built). Email me if you'd like a snapshot of this code to test. Regards, Jeremy Allison, Samba Team. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From lkcl at switchboard.net Mon Jun 28 17:53:01 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:09 2003 Subject: RPC auth In-Reply-To: Message-ID: On Mon, 28 Jun 1999, Hernan Ochoa wrote: > > hi. > > well, i think i found it. > in rpc_client/cli_pipe.c not quite. what you have found, here, is "NTLMSSP" over DCE/RPC. > in function create_rpc_bind_resp() there the NT/LM hashes are sent. no, they are used to generate 24-byte responses. > it says something about a 3-way handshake, and in the same file i guess > the RPC is negotiating the SSP (Security Service Provider) to use, yep. > and i > think samba is selecting NTLM, the default. everything is fitting now, i > think. > > is there any documentation about this? publicly available? no, sorry! > apart from cifsntdomain.txt? > > well, i'll keep reading the code. good for you. keep asking the questions. if it's a new topic, i'll answer. if the answers are already available, i won't (r.s.i). luke From pgmtekn at algonet.se Mon Jun 28 20:13:14 1999 From: pgmtekn at algonet.se (Michael Stockman) Date: Tue Dec 2 03:03:09 2003 Subject: SIGBUS Panic in smbd References: <000101bec12e$05a972c0$0500000a@pocket.wh.com> Message-ID: <009701bec1a2$a7c94200$0300a8c0@emil.pgmt> Hello, I do apologize for the following, but it is motivated. username.c is crap in regards to _Get_Pwnam and the passwd struct! The reason for the crashes the this thread started with is that ret->pw_passwd is __most__ likely a pointer to a static area and calling free on that can cause a crash. After calling free in _Get_Pwnam: ret->pw_passwd = strdup(...); is likely to cause memory bloat and may cause getpwnam to behave unpredictably, at least on linux systems. This is due to complete confusion in the code as to what is static memory and what is dynamically allocated. I propose that ret as well as the pointers in ret are pointers to static memory. Thus it would be forbidden to free the pointers, reassign the pointers and change their contents while the length of the pointed to memory is unknown. Basically, we need a structure of our own if that is really what we want to do. Should anyone in charge like me to try to cure this, please send me an e-mail. Regardless, it will need to be fixed. Best regards Michael Stockman pgmtekn-micke@algonet.se From lkcl at switchboard.net Mon Jun 28 20:28:14 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:09 2003 Subject: SIGBUS Panic in smbd In-Reply-To: <009701bec1a2$a7c94200$0300a8c0@emil.pgmt> Message-ID: michael, we have been intending to have a structure that can contain "unix" info in parallel with "nt" info for over a year. if you would like to replace all instances where "char* unix_name" and "uid_t unix_id" and "char* nt_name" and "SID *nt_sid" are used, with a single structure, please do so. if you wanted to wait for the "MfH(tm)", that might be a better idea. luke On Tue, 29 Jun 1999, Michael Stockman wrote: > Hello, > > I do apologize for the following, but it is motivated. > username.c is crap in regards to _Get_Pwnam and the passwd struct! > > The reason for the crashes the this thread started with is that ret->pw_passwd is __most__ likely a pointer to a static area and calling free on that can cause a crash. > > After calling free in _Get_Pwnam: ret->pw_passwd = strdup(...); is likely to cause memory bloat and may cause getpwnam to behave unpredictably, at least on linux systems. > > This is due to complete confusion in the code as to what is static memory and what is dynamically allocated. I propose that ret as well as the pointers in ret are pointers to static memory. Thus it would be forbidden to free the pointers, reassign the pointers and change their contents while the length of the pointed to memory is unknown. Basically, we need a structure of our own if that is really what we want to do. > > Should anyone in charge like me to try to cure this, please send me an e-mail. Regardless, it will need to be fixed. > > Best regards > Michael Stockman > pgmtekn-micke@algonet.se > > > Luke Kenneth Casson Leighton Samba and Network Development Samba Web site Internet Security Systems, Inc. Direct Dial: (678) 443-6183. ISS Front Desk: (678) 443-6000. From weave at hopi.dtcc.edu Mon Jun 28 20:54:10 1999 From: weave at hopi.dtcc.edu (Ken Weaverling) Date: Tue Dec 2 03:03:09 2003 Subject: SIGBUS Panic in smbd In-Reply-To: <009701bec1a2$a7c94200$0300a8c0@emil.pgmt> Message-ID: On Tue, 29 Jun 1999, Michael Stockman wrote: > Hello, > > I do apologize for the following, but it is motivated. > username.c is crap in regards to _Get_Pwnam and the passwd struct! > > The reason for the crashes the this thread started with is that > ret->pw_passwd is __most__ likely a pointer to a static area and > calling free on that can cause a crash. I've seen this myself. I just upgraded to 2.04b from 2.03 on a box that serves thousands of users. The panics started to occur. This is a debugger dump. Frame 0, pc 0x800535c4 (kill+12) Frame 1, pc 0x80043ca8 (abort+80) Frame 2, line 2386, routine smb_panic(why=0x001cfd38 -> "internal error"), file util.c Frame 3, line 47, routine fault_report(sig=11), file fault.c Error: General register 2 is not readable. Frame 4, line 66, routine sig_fault(sig=), file fault.c Frame 5, pc 0x8007e6f8 (__sigacthandler2+64) Frame 6, pc 0x80060bbc (realloc+2356) Frame 7, pc 0x80060a1c (realloc+1940) Frame 8, pc 0x800606c0 (realloc+1080) Frame 9, pc 0x80060eb4 (realloc+3116) Frame 10, pc 0x800600f0 (free+544) Frame 11, pc 0x8005fe94 (malloc+76) Frame 12, pc 0x80061240 (_findbuf+152) Frame 13, pc 0x80056ea4 (fgets+172) Frame 14, pc 0x80068cfc (getpwnam+92) Error: General register 2 is not readable. Frame 15, line 169, routine _Get_Pwnam(s=), file username.c Frame 16, line 195, routine Get_Pwnam(user=0xefffd298 -> "usertemp", allow_change=1), file username.c Error: General register 3 is not readable. Frame 17, line 298, routine add_session_user(user=), file password.c Frame 18, line 267, routine make_connection(service=0xefffebd8 -> "usertemp", user=0xefffefd8 -> "", password=0xeffff3d8 -> "", pwlen=0, dev=0xeffff7d8 -> "A:", vuid=101u, ecode=0xeffffbd8), file service.c Frame 19, line 316, routine reply_tcon_and_X(conn=0x0021dfe1, inbuf=0x0021dfb1 -> "", outbuf=0x0022e3c1 -> "", length=73, bufsize=61440), file reply.c Frame 20, line 539, routine switch_message(type=0, inbuf=0x0021dfb1 -> "", outbuf=0x0022e3c1 -> "", size=73, bufsize=61440), file process.c Frame 21, line 574, routine construct_reply(inbuf=0x0021dfb1 -> "", outbuf=0x0022e3c1 -> "", size=73, bufsize=61440), file process.c Frame 22, line 642, routine process_smb(inbuf=0x0021dfb1 -> "", outbuf=0x0022e3c1 -> ""), file process.c Frame 23, line 1027, routine smbd_process(), file process.c Frame 24, line 717, routine main(argc=2, argv=0xeffffe20), file server.c Frame 25, pc 0x104104 (_start+416) This is from a DG/UX m88k system. Please consider this a serious problem. SIGBUS isn't a nice thing! From timothy_d_cole at md.northgrum.com Mon Jun 28 21:55:59 1999 From: timothy_d_cole at md.northgrum.com (Cole, Timothy D.) Date: Tue Dec 2 03:03:09 2003 Subject: permissions/ownership Message-ID: <51FBD4A8EFD9D111BA7300A0C927DADB5630AE@xcgmd008.md.essd.northgrum.com> [ to Dave ] Just be careful that your users understand the behavior in 2.0.4b when modifying permissions, else they may have some nasty suprises (like I did). If the user makes any changes to the permissions of a file, Samba will silently strip or add mode bits to match the umask (create mask) and force mode, and drop suid/sgid/sticky bits too. 2.0.5 should have "less suprising" behavior. > -----Original Message----- > From: Jeremy Allison [SMTP:jallison@cthulhu.engr.sgi.com] > Sent: Monday, June 28, 1999 16:05 > To: Multiple recipients of list > Subject: Re: permissions/ownership > > Dave J. Andruczyk wrote: > > > > Is it possible to have a samba 2.0.4b machine (setup as a domain MEMBER) > > to have another NT server chaneg the ownership and permissions under > > explorer on a file stored on that samba server? Is this FULLY (i.e. > > completely, no apparant bugs/workaround needed) functional? > > Permissions yes From jallison at cthulhu.engr.sgi.com Mon Jun 28 22:00:45 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:09 2003 Subject: SIGBUS Panic in smbd References: Message-ID: <3777F08C.A09F72C4@engr.sgi.com> Ken Weaverling wrote: > > The reason for the crashes the this thread started with is that > > ret->pw_passwd is __most__ likely a pointer to a static area and > > calling free on that can cause a crash. > > I've seen this myself. I just upgraded to 2.04b from 2.03 on a box that > serves thousands of users. The panics started to occur. This is > a debugger dump. Ok - I want to get this straight. This is with a machine that has HAVE_GETPWANAM defined after configure, correct ? I see the bogus free() call in this case, I just want to make sure I fix this the right way. Can someone send me a man page for getpwanam() as I can't find it on the systems I have access to. Regards, Jeremy Allison, Samba Team. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From jallison at cthulhu.engr.sgi.com Mon Jun 28 22:14:50 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:09 2003 Subject: SIGBUS Panic in smbd References: Message-ID: <3777F3DA.7D1C82AC@engr.sgi.com> Ken Weaverling wrote: > I've seen this myself. I just upgraded to 2.04b from 2.03 on a box that > serves thousands of users. The panics started to occur. This is > a debugger dump. > > This is from a DG/UX m88k system. > > Please consider this a serious problem. SIGBUS isn't a nice thing! Ok, I found a getpwanam() man page on the Web. As far as I can tell just removing the line containing the free() call should fix it correctly in 2.0.4b. Commants anyone ? Regards, Jeremy Allison, Samba Team. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From pgmtekn at algonet.se Mon Jun 28 22:49:45 1999 From: pgmtekn at algonet.se (Michael Stockman) Date: Tue Dec 2 03:03:09 2003 Subject: SV: SIGBUS Panic in smbd References: Message-ID: <00f101bec1b8$88557e00$0300a8c0@emil.pgmt> Hello, Could I ask what MfH(tm) is and when it is expected to be ready, if that information is available? Should the summer get really rainy (or I descide to work even though it's sunny), I might replace all instances of the named variables, if that would contribute 'to the cause'. Best regards Michael Stockman pgmtekn-micke@algonet.se > michael, > > we have been intending to have a structure that can contain "unix" info in > parallel with "nt" info for over a year. > > if you would like to replace all instances where "char* unix_name" and > "uid_t unix_id" and "char* nt_name" and "SID *nt_sid" are used, with a > single structure, please do so. > > if you wanted to wait for the "MfH(tm)", that might be a better idea. > > luke > >>... From pgmtekn at algonet.se Mon Jun 28 23:04:07 1999 From: pgmtekn at algonet.se (Michael Stockman) Date: Tue Dec 2 03:03:09 2003 Subject: SV: SIGBUS Panic in smbd References: <3777F3DA.7D1C82AC@engr.sgi.com> Message-ID: <00f901bec1ba$88c14d40$0300a8c0@emil.pgmt> Hello, AFAIK (the passwd struct and the pointers in it is static memory) that would fix the SIGBUS, however it would open samba to completely inpredictable behaviour. Consider that when ret->pw_passwd = strdup() the static passwd struct is altered so that it points to a buffer of a most likely shorter size. A subsequent call to getpwnam where pw_passwd would be longer would cause it to write out of bounds. Even if all calls return the same length pw_passwd we'd still throw away memory on each call to _Get_Pwnam(). The ugliest hack that isn't completely unthinkable is to strcpy the string into pw_passwd (and that doesn't feel good while we don't know the size of the buffer)! Disclaimer: this relates to how the code looks in the head branch, I don't know how that differs from 2.0.4b. Best regards Michael Stockman pgmtekn-micke@algonet.se > Ken Weaverling wrote: > > > I've seen this myself. I just upgraded to 2.04b from 2.03 on a box that > > serves thousands of users. The panics started to occur. This is > > a debugger dump. > > > > This is from a DG/UX m88k system. > > > > Please consider this a serious problem. SIGBUS isn't a nice thing! > > Ok, I found a getpwanam() man page on the Web. As far as I > can tell just removing the line containing the free() call > should fix it correctly in 2.0.4b. > > Commants anyone ? > From jallison at cthulhu.engr.sgi.com Mon Jun 28 23:28:59 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:09 2003 Subject: SV: SIGBUS Panic in smbd References: <3777F3DA.7D1C82AC@engr.sgi.com> <00f901bec1ba$88c14d40$0300a8c0@emil.pgmt> Message-ID: <3778053B.479EE5FB@engr.sgi.com> Michael Stockman wrote: > > > Disclaimer: this relates to how the code looks in the head branch, I don't know how that differs from 2.0.4b. 2.0.x is what I care about at the moment. I will fix it in HEAD when I do a full analysis of what that code is doing. As far as I can see the pw_passwd is only read once and discarded (along with the pwent structure pointer) in 2.0.x - so the proposed fix should be safe. Regards, Jeremy Allison, Samba Team. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From weave at hopi.dtcc.edu Mon Jun 28 23:38:10 1999 From: weave at hopi.dtcc.edu (Ken Weaverling) Date: Tue Dec 2 03:03:09 2003 Subject: SIGBUS Panic in smbd In-Reply-To: <3777F08C.A09F72C4@engr.sgi.com> Message-ID: On Tue, 29 Jun 1999, Jeremy Allison wrote: > Ken Weaverling wrote: > > > > The reason for the crashes the this thread started with is that > > > ret->pw_passwd is __most__ likely a pointer to a static area and > > > calling free on that can cause a crash. > > > > I've seen this myself. I just upgraded to 2.04b from 2.03 on a box that > > serves thousands of users. The panics started to occur. This is > > a debugger dump. > > Ok - I want to get this straight. This is with a machine > that has HAVE_GETPWANAM defined after configure, correct ? Sorry to break bad news to you, but on this box, there is no getpwanam() and it isn't defined in config.h either. It looks like it is failing inside getpwnam()... btw, I have a machine that I can reproduce this everytime consistently. But if I log onto the same machine with a different account executing the same logon script, it's fine. Weird... dbx) up Frame 15, line 153, routine _Get_Pwnam(s=0xefffd2b8 -> "usertemp"), file username.c * 153 ret = getpwnam(s); (dbx) list 153 148 ****************************************************************************/ 149 static struct passwd *_Get_Pwnam(char *s) 150 { 151 struct passwd *ret; 152 * 153 ret = getpwnam(s); 154 if (ret) 155 { 156 #ifdef HAVE_GETPWANAM 157 struct passwd_adjunct *pwret; 158 pwret = getpwanam(s); (dbx) print s s = 0xefffd2b8 -> "usertemp" (dbx) print ret ret = 0xefffd1f1 (dbx) print *ret Warning: Unable to dereference pointer. Warning: Unable to dereference pointer. Warning: Unable to dereference pointer. Warning: Unable to dereference pointer. Warning: Unable to dereference pointer. Warning: Unable to dereference pointer. Warning: Unable to dereference pointer. *ret = { pw_name = 0x00fe9400 pw_passwd = 0x26ab0000 pw_uid = 632443008 pw_gid = 180262912 pw_age = 0x00002000 pw_comment = 0x1d540400 pw_gecos = 0x00001380 pw_dir = 0x0abe9880 pw_shell = 0x06027000 } From Tim.Potter at anu.edu.au Mon Jun 28 23:47:25 1999 From: Tim.Potter at anu.edu.au (Tim Potter) Date: Tue Dec 2 03:03:09 2003 Subject: SV: SIGBUS Panic in smbd In-Reply-To: <3778053B.479EE5FB@engr.sgi.com> References: <3777F3DA.7D1C82AC@engr.sgi.com> <00f901bec1ba$88c14d40$0300a8c0@emil.pgmt> <3778053B.479EE5FB@engr.sgi.com> Message-ID: <14200.2445.481794.137806@acronym.anu.edu.au> Jeremy Allison writes: > > Disclaimer: this relates to how the code looks in the head branch, > > I don't know how that differs from 2.0.4b. > > 2.0.x is what I care about at the moment. I will fix it in > HEAD when I do a full analysis of what that code is doing. > > As far as I can see the pw_passwd is only read once and > discarded (along with the pwent structure pointer) in > 2.0.x - so the proposed fix should be safe. This sounds similar to the bug I found in the HEAD branch wrt password caching. There is code in passdb/pass_check.c that can change the value of the pw_passwd field in the pass_check() function depending on which weird password shadowing functions the host OS supports. I thought it was only a problem in the new password caching code but perhaps it is present in SAMBA_2_0 as well. Tim. > > Regards, > > Jeremy Allison, > Samba Team. > -- Tim Potter, System Admin/Programmer "Disco Stu doesn't advertise" Advanced Computational Systems CRC, RSISE Bldg Australian National University, Canberra 0200, AUSTRALIA Ph: +61 2 62798813 Fax: +61 2 62798602 From lkcl at switchboard.net Mon Jun 28 23:23:31 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:09 2003 Subject: Replacing user references (char* etc) in smbd with a struct. In-Reply-To: <00f101bec1b8$88557e00$0300a8c0@emil.pgmt> Message-ID: > Could I ask what MfH(tm) is and when it is expected to be ready, if > that information is available? Should the summer get really rainy (or > I descide to work even though it's sunny), I might replace all > instances of the named variables, if that would contribute 'to the > cause'. well, my recommendation would be to go ahead. if anyone has any objections to that, please speak within 48 hours. use the latest cvs (no tag, so using cvs main, see http://samba.org/cvs.html), doing this daily: cp -r samba-current samba-backup cd samba-current cvs -t update [check your patch hasn't been botched]. the struct you use should probably contain: - char* unix_username - char* unix_pwd_crypt - uid_t unix_uid - gid_t unix_gid - gid_t unix_groups[] - int num_unix_groups - char* nt_username - SID nt_user_sid - SID nt_group_sid - RID nt_group_rids[] - int num_nt_groups ...although the group (both unix and nt) are probably overkill. i think that you will find exactly the structure you will need to start from something like current_user. check also in 2.0.X branch: jeremy rewrote the unix security code. luke From lkcl at switchboard.net Mon Jun 28 23:15:50 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:09 2003 Subject: SV: SIGBUS Panic in smbd In-Reply-To: <00f101bec1b8$88557e00$0300a8c0@emil.pgmt> Message-ID: On Tue, 29 Jun 1999, Michael Stockman wrote: > Hello, > > Could I ask what MfH(tm) is and when it is expected to be ready, if > that information is available? Should the summer get really rainy (or > I descide to work even though it's sunny), I might replace all > instances of the named variables, if that would contribute 'to the > cause'. The Merge From Hell (trademark). it's a merge of 2.0.X and 2.1prealpha. From jallison at cthulhu.engr.sgi.com Tue Jun 29 00:07:48 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:09 2003 Subject: SV: SIGBUS Panic in smbd References: <3777F3DA.7D1C82AC@engr.sgi.com> <00f901bec1ba$88c14d40$0300a8c0@emil.pgmt> <3778053B.479EE5FB@engr.sgi.com> <14200.2445.481794.137806@acronym.anu.edu.au> Message-ID: <37780E54.94049DD1@engr.sgi.com> Tim Potter wrote: > > This sounds similar to the bug I found in the HEAD branch wrt password > caching. There is code in passdb/pass_check.c that can change the > value of the pw_passwd field in the pass_check() function depending on > which weird password shadowing functions the host OS supports. > > I thought it was only a problem in the new password caching code but > perhaps it is present in SAMBA_2_0 as well. Hmmm. But even if is does change the pw_passwd field, that field is supposed to be a pointer into a static area, so it shouldn't matter so long as no-one calls free() on it (which in the 2.0.x branch, only the conditional code in HAVE_GETPWANAM does - I've now removed that). I still cannot see why this thing is crashing Ken's system, unless the underlying passwd functions are keeping a private malloced area that they are doing a free() on on second and subsequent calls.... Ken - do you have purify on that box ? I'll look into making sure the pw_passwd field is restored after use (although this gets a bit tricky). Jeremy. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From sharpe at ns.aus.com Tue Jun 29 01:08:56 1999 From: sharpe at ns.aus.com (Richard Sharpe) Date: Tue Dec 2 03:03:09 2003 Subject: Modes on directories vs force group etc Message-ID: <3.0.5.32.19990629100856.00850840@mail.adelaide.on.net> Hi, I am interested in the history of parameters like force user and force group vs setting SETUID and SETGID bits on a directory etc ... What are the pros and cons? Clearly, in a directory with the T bit set, the UID gets set to the logged on user. Regards ------- Richard Sharpe, sharpe@ns.aus.com, NS Computer Software and Services P/L, Samba (Team member www.samba.org), Ethereal (Team member www.zing.org) Co-author, SAMS Teach Yourself Samba in 24 Hours From rgooch at atnf.csiro.au Tue Jun 29 00:46:18 1999 From: rgooch at atnf.csiro.au (Richard Gooch) Date: Tue Dec 2 03:03:09 2003 Subject: VFS event hooks in Linux Message-ID: <199906290046.KAA10738@vindaloo.atnf.CSIRO.AU> Hi, all. Some of you may have seen the recent discussions on linux-kernel about VFS event hooks. The idea is to have the kernel send some kind of event when an inode is written (for a directory this means you get to see when a leaf node is created or removed). I've implemented such a scheme based on poll(2), which was Linus' preferred method. Following on from some private discussions, it's been brought to my attention that Samba would benefit from VFS event hooks. Could someone please explain what level of support is useful? The poll(2)-based scheme I implemented requires an open file on each inode that you want to watch. This is fine for simple applications like a file browser, where you can easily keep the directory open. It may not be appropriate for Samba, if you want to be notified when *any* file in the exported volume has changed, as it would require a ridiculous number of open files. So I'd like to establish just what the requirements for Samba are. An alternative scheme I'd devised would allow you to keep just a single open file per filesystem, which is used to receive events when any inode in that FS is written to. An event queue would be maintained, to which the inode number would be written. Is this scheme an improvement? If it is, then please give me your arguments and I'll raise them with Linus. Regards, Richard.... From rgooch at atnf.csiro.au Tue Jun 29 00:47:06 1999 From: rgooch at atnf.csiro.au (Richard Gooch) Date: Tue Dec 2 03:03:09 2003 Subject: VFS event hooks in Linux In-Reply-To: <199906290046.KAA10738@vindaloo.atnf.CSIRO.AU> References: <199906290046.KAA10738@vindaloo.atnf.CSIRO.AU> Message-ID: <199906290047.KAA10761@vindaloo.atnf.CSIRO.AU> Richard Gooch writes: > Hi, all. Some of you may have seen the recent discussions on > linux-kernel about VFS event hooks. The idea is to have the kernel > send some kind of event when an inode is written (for a directory this > means you get to see when a leaf node is created or removed). P.S. I'm not subscribed to the list, so please Cc me directly. Regards, Richard.... From jallison at cthulhu.engr.sgi.com Tue Jun 29 01:18:21 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:09 2003 Subject: VFS event hooks in Linux References: <199906290046.KAA10738@vindaloo.atnf.CSIRO.AU> Message-ID: <37781EDD.379B825B@engr.sgi.com> Richard Gooch wrote: > > Following on from some private discussions, it's been brought to my > attention that Samba would benefit from VFS event hooks. Could someone > please explain what level of support is useful? ChangeNotify is the SMB call Samba uses to return to a Windows client that a directory tree has been modified and should be re-scanned by the client. ChangeNotify can act just on one directory, or on a complete tree (realistically it is only used on a per-directory basis). > The poll(2)-based scheme I implemented requires an open file on each > inode that you want to watch. This is fine for simple applications > like a file browser, where you can easily keep the directory open. > > It may not be appropriate for Samba, if you want to be notified when > *any* file in the exported volume has changed, as it would require a > ridiculous number of open files. Agreed. This would not work. > An alternative scheme I'd devised would allow you to keep just a > single open file per filesystem, which is used to receive events when > any inode in that FS is written to. An event queue would be > maintained, to which the inode number would be written. > > Is this scheme an improvement? If it is, then please give me your > arguments and I'll raise them with Linus. That sounds better, and also similar to the kernel oplock notification system that was already implemented in IRIX for Samba. The ideal interface would be one that acted on a direcory inode and reported changes in any inode (file or directory) hierarchically "under" that inode. If this is not doable, then a generic filesystem inode notify is better than nothing, although may cause many false positives on a heavily used filesystem (a home directory server for example). This is also similar to the "FAM" interface in IRIX (one fd per watched filesystem (via an "imon" pseudo-device) and would allow me to generalize the Samba ChangeNotify interface to be fd based. I've been thinking of doing this based on the IRIX fam interface already, but didn't want to make Samba look too IRIX-specific (in case people got funny ideas). This is good news, as currently Samba has to scan each watched directory to notice changes (which it does via a configurable, currently 60 second, timeout). Cheers, Jeremy Allison, Samba Team. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From rgooch at atnf.csiro.au Tue Jun 29 01:45:00 1999 From: rgooch at atnf.csiro.au (Richard Gooch) Date: Tue Dec 2 03:03:09 2003 Subject: VFS event hooks in Linux In-Reply-To: <37781EDD.379B825B@engr.sgi.com> References: <199906290046.KAA10738@vindaloo.atnf.CSIRO.AU> <37781EDD.379B825B@engr.sgi.com> Message-ID: <199906290145.LAA11253@vindaloo.atnf.CSIRO.AU> Jeremy Allison writes: > Richard Gooch wrote: > > > > Following on from some private discussions, it's been brought to my > > attention that Samba would benefit from VFS event hooks. Could someone > > please explain what level of support is useful? > > ChangeNotify is the SMB call Samba uses to return to a Windows > client that a directory tree has been modified and should be > re-scanned by the client. So if somewhere deep in a directory tree a change is made, the SMB client will rescan the *entire* tree? > ChangeNotify can act just on one directory, or on a complete tree > (realistically it is only used on a per-directory basis). Why do you say that? Used by whom? The client or the server? > > An alternative scheme I'd devised would allow you to keep just a > > single open file per filesystem, which is used to receive events when > > any inode in that FS is written to. An event queue would be > > maintained, to which the inode number would be written. > > > > Is this scheme an improvement? If it is, then please give me your > > arguments and I'll raise them with Linus. > > That sounds better, and also similar to the kernel oplock > notification system that was already implemented in IRIX > for Samba. > > The ideal interface would be one that acted on a direcory > inode and reported changes in any inode (file or directory) > hierarchically "under" that inode. If this is not doable, > then a generic filesystem inode notify is better than nothing, > although may cause many false positives on a heavily used > filesystem (a home directory server for example). This may be possible too. Just tag a directory somewhere under / (it could even be /), and when an inode changes, walk up the directory entry tree looking for the tagged inode. You'd maintain a global count of tagged inodes, so that if it is 0, you can skip the walk. This would of course slow down inode writes on other filesystems or parts of the namespace as well. An alternative would be to make this per-FS. You can tag an inode anywhere in a FS, which also tags the superblock. You only walk up the tree if the FS is tagged. Unwatched filesystems would not suffer the walk penalty. It would of course require a bit more effort from Samba when exporting a tree with multiple filesystems beneath it. > This is good news, as currently Samba has to scan > each watched directory to notice changes (which it does > via a configurable, currently 60 second, timeout). So it always scans every directory in the exported volume?!? Do the ChangeNotify events apply to directory writes only (i.e. writing to a regular file is ignored)? Regards, Richard.... From pgmtekn at algonet.se Tue Jun 29 07:23:27 1999 From: pgmtekn at algonet.se (Michael Stockman) Date: Tue Dec 2 03:03:09 2003 Subject: SV: SIGBUS Panic in smbd References: <37780E54.94049DD1@engr.sgi.com> Message-ID: <014901bec200$4ee0daa0$0300a8c0@emil.pgmt> Hello, > > > > This sounds similar to the bug I found in the HEAD branch wrt password > > caching. There is code in passdb/pass_check.c that can change the > > value of the pw_passwd field in the pass_check() function depending on > > which weird password shadowing functions the host OS supports. > > > > I thought it was only a problem in the new password caching code but > > perhaps it is present in SAMBA_2_0 as well. > > Hmmm. But even if is does change the pw_passwd field, > that field is supposed to be a pointer into a static > area, so it shouldn't matter so long as no-one calls > free() on it (which in the 2.0.x branch, only the > conditional code in HAVE_GETPWANAM does - I've now > removed that). It could matter, as at least on my linux where the structure returned by getpwnam() is the same on each call -> there is a risk of memory corruption or strange behaviour, if HAVE_GETPWANAM is defined. Assume that the passwd_adjunct->pwa_passwd points to a shorter memory area than passwd->pw_passwd, getpwnam could write out of bounds. If that doesn't happen (and I don't _think_ it will) the contents of the passwd->pw_passwd will change on each call to getpwanam since it points to the same memory as the passwd_adjunct->pwa_passwd (unexpected?). In this case that doesn't matter but it could cause confusion if these functions are used at other places, and regardless it is dirty (microsoftish) programming and definiatly a bug. We must differ between assigning pointers to each other and changing the contents of strings (it isn't the same thing). > I still cannot see why this thing is crashing Ken's > system, unless the underlying passwd functions are > keeping a private malloced area that they are doing > a free() on on second and subsequent calls.... That could be, and since we don't know and it could be different between different systems, we shouldn't free the pointers or reassign them to either static or allocated memory (they are owned by the library, not us). I do still propose strcpy as the dirty hack and a struct of our own as the fix. I will start looking into the unix<->nt struct this afternoon or tomorrow. > Ken - do you have purify on that box ? > > I'll look into making sure the pw_passwd field is > restored after use (although this gets a bit > tricky). This would be an almost good approach, but quite unmanagable I think (for the same reason I think that getpwnam and getpwanam deals in static memory, it is virtually impossible to know when to free/reset the pointers unless you make a function for that which must be called when we're done with the struct). > Jeremy. Best regards Michael Stockman pgmtekn-micke@algonet.se From robert at vps.co.za Tue Jun 29 14:06:55 1999 From: robert at vps.co.za (Robert Sandilands) Date: Tue Dec 2 03:03:09 2003 Subject: VFS event hooks in Linux In-Reply-To: <199906290145.LAA11253@vindaloo.atnf.CSIRO.AU> Message-ID: On Tue, 29 Jun 1999, Richard Gooch wrote: > Jeremy Allison writes: > > Richard Gooch wrote: > > > > So if somewhere deep in a directory tree a change is made, the SMB > client will rescan the *entire* tree? If you look at the speed it happens at, it may be possible that Windoze work that way :-) > This may be possible too. Just tag a directory somewhere under / (it > could even be /), and when an inode changes, walk up the directory > entry tree looking for the tagged inode. You'd maintain a global count > of tagged inodes, so that if it is 0, you can skip the walk. > This would of course slow down inode writes on other filesystems or > parts of the namespace as well. If I understand correctly it would be very slow. The type of message generated needs to be processed as quickly as possible. So having to walk trees etc. is not the best idea when performance is an issue. > An alternative would be to make this per-FS. You can tag an inode > anywhere in a FS, which also tags the superblock. You only walk up the > tree if the FS is tagged. Unwatched filesystems would not suffer the > walk penalty. The idea of making it per-FS is a good idea. I've written on-access scanners for Dos, Windows 3.x, Windows 9x, Windows NT and Novell OS. I know that it is bad examples, but here goes my experience :-) With Dos you caught the "interrupts" generated to handle the files and you processed them... That is basically equivalent to taking over the library functions for every posible file-API call - bad idea. For the other you "connect" to a volume registering a call-back function that got called for every possible file access on that volume. Some of them you could specify a limited filter which defined for what types of file access you wanted calls generated. Every call is accompanied with enough information to directly identify the file/directory/direct disk access taking place... This implies you need to filter the calls you need yourself and act on them.. Normally no API calls is needed to get any more information on the file. On basically all these filesystems it is also a blocking call which means you have to be quick or people complain a lot. This approach is not very practical for Linux/Unix but it gives you an idea of how other people do it. _________________________________________________________________________ Silly little things like representing anybody else is not of importance ------------------------------------------------------------------------- Robert Sandilands - Peace is when the music of the soul harmonizes with the music of Life Tel: +27-12-841-2106, Fax: +27-12-841-4670, Email: robert@vps.co.za ------------------------------------------------------------------------- From rgooch at atnf.csiro.au Tue Jun 29 14:24:51 1999 From: rgooch at atnf.csiro.au (Richard Gooch) Date: Tue Dec 2 03:03:10 2003 Subject: VFS event hooks in Linux In-Reply-To: References: <199906290145.LAA11253@vindaloo.atnf.CSIRO.AU> Message-ID: <199906291424.AAA16991@vindaloo.atnf.CSIRO.AU> Robert Sandilands writes: > > On Tue, 29 Jun 1999, Richard Gooch wrote: > > > Jeremy Allison writes: > > > Richard Gooch wrote: > > > > > > So if somewhere deep in a directory tree a change is made, the SMB > > client will rescan the *entire* tree? > > If you look at the speed it happens at, it may be possible that Windoze > work that way :-) > > > This may be possible too. Just tag a directory somewhere under / (it > > could even be /), and when an inode changes, walk up the directory > > entry tree looking for the tagged inode. You'd maintain a global count > > of tagged inodes, so that if it is 0, you can skip the walk. > > This would of course slow down inode writes on other filesystems or > > parts of the namespace as well. > > If I understand correctly it would be very slow. The type of message > generated needs to be processed as quickly as possible. So having to > walk trees etc. is not the best idea when performance is an issue. Actually, walking up the directory entry (dentry) tree would be fairly fast. The Linux dentry mechanism is extremely fast. The killer would be if the client then scans a large part of the tree. > > An alternative would be to make this per-FS. You can tag an inode > > anywhere in a FS, which also tags the superblock. You only walk up the > > tree if the FS is tagged. Unwatched filesystems would not suffer the > > walk penalty. > > The idea of making it per-FS is a good idea. Well, I've been talking to Linus about this, and he hates the idea. He doesn't like the idea of throwing anonymous events to user space, claiming that it's a bad design. He suggested that if Samba really needed this information, it might be better to put it in kernel space so it can cheaply check the inodes (I presume he was referring to avoiding syscall overheads). However, putting it in the kernel wouldn't help since many inodes in a directory tree wouldn't be in the inode cache anyway. So the real limit is the disc I/O on countless thousands of inode lookups. Somehow I doubt that Samba stat()s a large number of files every 60 seconds. It would load the system too much. So I'd like to revist the requirements again. What is actually necessary for SMB support? What must be done at the server side and what happens at the client side? Let me come to this from another direction. Suppose that an SMB server need only send directory upate events to clients that have the directory open (say in their browser). In that case, it would make sense for the SMB protocol to have the server know that a client has the directory open. In that case, the VFS poll() patch I've implemented for Linux should do fine. You just need one open fd per client/browser. Since I don't know SMB at all, I have no idea if this reflects reality. Regards, Richard.... From timothy_d_cole at md.northgrum.com Tue Jun 29 15:56:47 1999 From: timothy_d_cole at md.northgrum.com (Cole, Timothy D.) Date: Tue Dec 2 03:03:10 2003 Subject: Modes on directories vs force group etc Message-ID: <51FBD4A8EFD9D111BA7300A0C927DADB5630AF@xcgmd008.md.essd.northgrum.com> > -----Original Message----- > From: Richard Sharpe [SMTP:sharpe@ns.aus.com] > Sent: Monday, June 28, 1999 20:33 > To: Multiple recipients of list > Subject: Modes on directories vs force group etc > > Hi, > > I am interested in the history of parameters like force user and force > group vs setting SETUID and SETGID bits on a directory etc ... > > What are the pros and cons? > force user in Samba essentially cause the logged in user to "become" the specified user for all file operations. It should be understood that it's not a mechanism to "give away" files to the specified user. It's only safe (and useful) in very specific settings. force group simply sets the logged in user's primary group to the specified group, preserving any other group memberships. It is more appropriate to situations where you wish a bunch of users to share files with each other -- after all, that's what groups are for. It also allows you to use that group to control what can be shared and what cannot. It's still probably not appropriate for shares used by a number of different projects. It is not necessary for the user to normally be a member of this group. smb.conf(5) goes into a little more detail about this. > Clearly, in a directory with the T bit set, the UID gets set to the logged > on user. > Well, that's true, strictly speaking, but the UID is always set to the user when creating a file whether or not the 'T' bit is set (unless you're using force user in Samba, in which case the logged in user will actually be that user anyway). 't' has no significance for creating files. More on the various bits (feel free to correct me if I'm off somewhere): All three of the special bits were originally only meaningful for executables. suid and sgid, 04000 and 02000 (and the notion of effective group and user ids) were introduced early in Unix history; Thompson, I believe, actually got a patent on them. At that time, their only significance was to set the effective user or group id of the new process to the user or group id of the file, respectively. The "sticky" bit, 't', 01000, I think predates the suid and sgid bits. It inidicated that the executable's text segment should be saved on the swap media after the process terminated. This was especially useful for often-run tools like "ls". (originally, Unix swapped entire processes in and out of core instead of paging, as it does today) As virtual memory, persistent storage performance and disk cacheing got better, its original meaning became obsolete. As time passed, the special bits (so far unused for non-executables) were called into service to control other aspects of Unix behavior. One nagging problem in world-writable shared directories like /tmp had always been a user's ability to delete files created and owned by other users. For non-public directories, that's often desirable, but if just anyone can come in and, say, delete or replace one of your text editor's working files, that's a potential headache, as well as a security problem. As a result of such problems, the "sticky" bit found a new use in specifying that links to a file could not be renamed or removed from a directory by anyone but the directory or file owner. It does not have any influence over other operations, including the creation of links. (as a side note, the new use of the sticky bit also made the owner of a symlink meaningful for the first time, as it now determines who can delete or rename a symlink in a "sticky" directory) The current use of sgid on directories was introduced in BSD. It causes any new files or subdirectories in such a directory to be created with their parent's group, and new subdirectories to inherit their parent's sgid bit, _iff the creating user is a member of that group_. More recently, with the introduction of mandatory locking in Unix, the sgid bit was pressed into service in yet another role: if sgid is set on a file for which the group does not have execute permission, fcntl() locks on the file will be mandatory (causing a process to block if it tries to operate on a portion of a file locked by someone else), else fcntl() will observe the traditional, discretionary, Unix behavior. From jallison at cthulhu.engr.sgi.com Tue Jun 29 16:33:45 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:10 2003 Subject: SV: SIGBUS Panic in smbd References: <37780E54.94049DD1@engr.sgi.com> <014901bec200$4ee0daa0$0300a8c0@emil.pgmt> Message-ID: <3778F569.7B976F26@engr.sgi.com> Michael Stockman wrote: > > This would be an almost good approach, but quite unmanagable I think > (for the same reason I think that getpwnam and getpwanam deals in > static memory, it is virtually impossible to know when to free/reset > the pointers unless you make a function for that which must be called > when we're done with the struct). Actually I have a simpler plan I'll implement. I will create a static struct passwd whose contents I control via the Get_Pass() function. This will point to Samba controlled memory and will be totally managed by Samba - the system function info will be copied into it. This should fix the problem permanently. Cheers, Jeremy. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From lkcl at switchboard.net Tue Jun 29 17:57:13 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:10 2003 Subject: VFS event hooks in Linux In-Reply-To: <199906290145.LAA11253@vindaloo.atnf.CSIRO.AU> Message-ID: in nt, ChangeNotify events occur on "objects", and can occur recursively. an "object" can be a file, directory, printer, registry entry, process, partition etc. On Tue, 29 Jun 1999, Richard Gooch wrote: > Jeremy Allison writes: > > Richard Gooch wrote: > > > > > > Following on from some private discussions, it's been brought to my > > > attention that Samba would benefit from VFS event hooks. Could someone > > > please explain what level of support is useful? > > > > ChangeNotify is the SMB call Samba uses to return to a Windows > > client that a directory tree has been modified and should be > > re-scanned by the client. > > So if somewhere deep in a directory tree a change is made, the SMB > client will rescan the *entire* tree? yes. if the smb client has file /directory handles open on that tree, for example, say a user has "explorer.exe" open, viewing but otherwise doing absolutely nothing, on a share. > > ChangeNotify can act just on one directory, or on a complete tree > > (realistically it is only used on a per-directory basis). From jallison at cthulhu.engr.sgi.com Tue Jun 29 18:30:18 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:10 2003 Subject: VFS event hooks in Linux References: <199906290145.LAA11253@vindaloo.atnf.CSIRO.AU> <199906291424.AAA16991@vindaloo.atnf.CSIRO.AU> Message-ID: <377910BA.7D935061@engr.sgi.com> Richard Gooch wrote: > > Well, I've been talking to Linus about this, and he hates the idea. He > doesn't like the idea of throwing anonymous events to user space, > claiming that it's a bad design. Well it works for the kernel oplock code :-). > He suggested that if Samba really needed this information, it might be > better to put it in kernel space so it can cheaply check the inodes (I > presume he was referring to avoiding syscall overheads). I hope he doesn't mean Samba here. Putting Samba in the kernel would be a very *bad* idea :-). > Somehow I doubt that Samba stat()s a large number of files every 60 > seconds. It would load the system too much. No, that's exactly what it has to do to provide close-to-NT ChangeNotify semantics. It has to scan every directory the client has expressed an interest in. > So I'd like to revist the > requirements again. What is actually necessary for SMB support? What > must be done at the server side and what happens at the client side? Client opens a directory. Client issues a ChangeNotify request on directory handle to server. Client request completes when change occurs (it's a one shot event). > Let me come to this from another direction. Suppose that an SMB server > need only send directory upate events to clients that have the > directory open (say in their browser). In that case, it would make > sense for the SMB protocol to have the server know that a client has > the directory open. In that case, the VFS poll() patch I've > implemented for Linux should do fine. You just need one open fd per > client/browser. That works as it is close to the desired semantics (the server knows the client has a directory open). The problem is that the NT semantics allow a client to set notification on a change in a directory *or any subdirectory within it*, although how many clients actually use that is open to debate (no one has complained about the current Samba behaviour, which is only to scan the current directory). Regards, Jeremy Allison, Samba Team. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From jallison at cthulhu.engr.sgi.com Tue Jun 29 18:34:18 1999 From: jallison at cthulhu.engr.sgi.com (Jeremy Allison) Date: Tue Dec 2 03:03:10 2003 Subject: VFS event hooks in Linux References: <199906290046.KAA10738@vindaloo.atnf.CSIRO.AU> <37781EDD.379B825B@engr.sgi.com> <199906290145.LAA11253@vindaloo.atnf.CSIRO.AU> Message-ID: <377911AA.5BEED1BF@engr.sgi.com> Richard Gooch wrote: > So if somewhere deep in a directory tree a change is made, the SMB > client will rescan the *entire* tree? Actually, the server is supposed to send a list of what changed to the client. This is hard for Samba, so we cheat by returning a special error that means "so much changed, I can't tell you about all of it - please re-scan yourself". > > ChangeNotify can act just on one directory, or on a complete tree > > (realistically it is only used on a per-directory basis). > > Why do you say that? Used by whom? The client or the server? Requested by the client. > > This is good news, as currently Samba has to scan > > each watched directory to notice changes (which it does > > via a configurable, currently 60 second, timeout). > > So it always scans every directory in the exported volume?!? Nope. Only those directories the clients have issued a ChangeNotify call upon. > Do the ChangeNotify events apply to directory writes only > (i.e. writing to a regular file is ignored)? No - in typical MS fashion there are about 10 different things a client can request a watch-on-change upon. Realistically the clients only really care about new files/attribute changes/old file writes. Regards, Jeremy Allison, Samba Team. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. -------------------------------------------------------- From pgmtekn at algonet.se Tue Jun 29 18:41:25 1999 From: pgmtekn at algonet.se (Michael Stockman) Date: Tue Dec 2 03:03:10 2003 Subject: SV: SIGBUS Panic in smbd References: <37780E54.94049DD1@engr.sgi.com> <014901bec200$4ee0daa0$0300a8c0@emil.pgmt> <3778F569.7B976F26@engr.sgi.com> Message-ID: <008f01bec25f$000a28a0$0300a8c0@emil.pgmt> Hello, Yes! That is the way to go! Then we have our own struct that we can do anything we like with. It appears as passdb/check_pass.c will need to be corrected too (in the 2.0 branch), the code was moved from there to _Get_Pwnam in the head branch (that also needs fixing). > Michael Stockman wrote: > > > > This would be an almost good approach, but quite unmanagable I think > > (for the same reason I think that getpwnam and getpwanam deals in > > static memory, it is virtually impossible to know when to free/reset > > the pointers unless you make a function for that which must be called > > when we're done with the struct). > > Actually I have a simpler plan I'll implement. I will > create a static struct passwd whose contents I control > via the Get_Pass() function. This will point to Samba > controlled memory and will be totally managed by Samba > - the system function info will be copied into it. > > This should fix the problem permanently. Best regards Michael Stockman pgmtekn-micke@algonet.se From lkcl at switchboard.net Tue Jun 29 19:42:08 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:10 2003 Subject: improved authentication support. Message-ID: if LmCompatibilityLevel=0x5 is in use at your site on domain controllers and smbclient or rpcclient fail to work as a result: - obtain the latest cvs main, and enable "client ntlmv2 = auto". luke Luke Kenneth Casson Leighton Samba and Network Development Samba Web site Internet Security Systems, Inc. From lkcl at switchboard.net Tue Jun 29 21:21:42 1999 From: lkcl at switchboard.net (Luke Kenneth Casson Leighton) Date: Tue Dec 2 03:03:10 2003 Subject: Groups with Samba+LDAP PDC: schema, help needed In-Reply-To: Message-ID: Simon Murcott has volunteered to do this, he can get to it next week. anyone else want to help, speak now :) thx simon, luke From greg at discreet.com Tue Jun 29 14:35:19 1999 From: greg at discreet.com (Greg Dickie) Date: Tue Dec 2 03:03:10 2003 Subject: VFS event hooks in Linux In-Reply-To: <199906291424.AAA16991@vindaloo.atnf.CSIRO.AU> Message-ID: This is REALLY not my area of expertise but I'm sure Jeremy will know more about this. IRIX has a thing called a FAM (File alteration monitor) which I believe has a similar function to what you are looking for. Perhaps you could mimic that mechanism and it would be enough? Greg On 29-Jun-99 Richard Gooch wrote: > Robert Sandilands writes: >> >> On Tue, 29 Jun 1999, Richard Gooch wrote: >> >> > Jeremy Allison writes: >> > > Richard Gooch wrote: >> > > > >> > So if somewhere deep in a directory tree a change is made, the SMB >> > client will rescan the *entire* tree? >> >> If you look at the speed it happens at, it may be possible that Windoze >> work that way :-) >> >> > This may be possible too. Just tag a directory somewhere under / (it >> > could even be /), and when an inode changes, walk up the directory >> > entry tree looking for the tagged inode. You'd maintain a global count >> > of tagged inodes, so that if it is 0, you can skip the walk. >> > This would of course slow down inode writes on other filesystems or >> > parts of the namespace as well. >> >> If I understand correctly it would be very slow. The type of message >> generated needs to be processed as quickly as possible. So having to >> walk trees etc. is not the best idea when performance is an issue. > > Actually, walking up the directory entry (dentry) tree would be fairly > fast. The Linux dentry mechanism is extremely fast. The killer would > be if the client then scans a large part of the tree. > >> > An alternative would be to make this per-FS. You can tag an inode >> > anywhere in a FS, which also tags the superblock. You only walk up the >> > tree if the FS is tagged. Unwatched filesystems would not suffer the >> > walk penalty. >> >> The idea of making it per-FS is a good idea. > > Well, I've been talking to Linus about this, and he hates the idea. He > doesn't like the idea of throwing anonymous events to user space, > claiming that it's a bad design. > > He suggested that if Samba really needed this information, it might be > better to put it in kernel space so it can cheaply check the inodes (I > presume he was referring to avoiding syscall overheads). > > However, putting it in the kernel wouldn't help since many inodes in a > directory tree wouldn't be in the inode cache anyway. So the real > limit is the disc I/O on countless thousands of inode lookups. > > Somehow I doubt that Samba stat()s a large number of files every 60 > seconds. It would load the system too much. So I'd like to revist the > requirements again. What is actually necessary for SMB support? What > must be done at the server side and what happens at the client side? > > Let me come to this from another direction. Suppose that an SMB server > need only send directory upate events to clients that have the > directory open (say in their browser). In that case, it would make > sense for the SMB protocol to have the server know that a client has > the directory open. In that case, the VFS poll() patch I've > implemented for Linux should do fine. You just need one open fd per > client/browser. > > Since I don't know SMB at all, I have no idea if this reflects > reality. > > Regards, > > Richard.... --------------------------------------------------------------------- Greg Dickie Just A Guy* *from discreet (the logic is gone) Montreal (514) 954-7171 greg@discreet.com From mlist at intergrafix.net Tue Jun 29 21:45:57 1999 From: mlist at intergrafix.net (Admin Mailing Lists) Date: Tue Dec 2 03:03:10 2003 Subject: smbmount file refreshing Message-ID: Ok, I know smbmount isn't supported in samba, but maybe some samba users can address this, as well as Mike who this is cc:'d to. Scenario: Windows NT 4 Server with sp5. Caldera Linux client with smbmount (tried version from samba v1.9.18 and v2.0.4) Running a RADIUS server on the NT box. The directory that the RADIUS log file is in is set up as a share. The RADIUS log filesize changes continously. With smbmount i'm mounting said share so my unix scripts can parse the log file. The scripts only parse NEW info/bytes every 2 minutes (previous run filesize is saved and compared to the current size of the logfile) Problem: Sporadically (for usually periods of 6-12 minutes) the log filesize and file contents will not update on the unix end. NT is the only thing that writes to the file. Even doing ls -l or stat() on the file does not show the updated size. Even if size is updated, contents not necessarily are. Some people have told me that this is because smbmount is reading cached info. Is there any way this can be remedied? Thanx, -Tony .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. Anthony J. Biacco Network Administrator/Engineer admin@intergrafix.net Intergrafix Internet Services "Dream as if you'll live forever, live as if you'll die today" http://cygnus.ncohafmuta.com http://www.intergrafix.net .-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-. From abakun at reac.com Tue Jun 29 22:36:41 1999 From: abakun at reac.com (Andy Bakun) Date: Tue Dec 2 03:03:10 2003 Subject: patch for FILE: and NE??: "print to file" problems Message-ID: <37794A79.87D7DAB8@reac.com> In http://us1.samba.org/listproc/samba-technical/3697.html I described a problem I was having with files being generated named FILE: and NE??: when telling the printer driver to print to a file. These files would either contain the print output or be empty. Included is a patch which adds these two patterns to the list of "restricted msdos filenames". In my tests, the applications that did have the problem of generating these files and didn't prompt for a filename to save the printer output to works as it should now. Unfortunately, I lost the list of people who sent mail to me saying they were having the same problem. Anyway, could those of you who have been experiencing this problem please try this patch out and let us know if it fixes anything. Andy. --------- cut 8< ----------- *** smbd/mangle.c.orig Tue Jun 29 16:58:38 1999 --- smbd/mangle.c Tue Jun 29 17:13:35 1999 *************** *** 213,221 **** --- 213,228 ---- case 'N': if( 0 == strcmp( p, "UL" ) ) return( True ); + /* NE??, where ?? is a two digit number, NT uses this for dynamic printer ports */ + if( *p == 'E' && isdigit((int)p[1]) && isdigit((int)p[2]) && p[3] == 0 ) + return( True ); break; case 'P': if( 0 == strcmp( p, "RN" ) ) + return( True ); + break; + case 'F': + if( 0 == strcmp( p, "ILE" ) ) return( True ); break; } --------- cut 8< ----------- From sharpe at ns.aus.com Wed Jun 30 02:50:05 1999 From: sharpe at ns.aus.com (Richard Sharpe) Date: Tue Dec 2 03:03:10 2003 Subject: Linux Users IDs and NT Message-ID: <3.0.5.32.19990630115005.00959d70@mail.adelaide.on.net> >Resent-date: Wed, 30 Jun 1999 08:36:36 +0930 >Date: Wed, 30 Jun 1999 08:36:25 +0930 (CST) >Resent-from: linuxsa@linuxsa.org.au >From: mtippett@ticons.com.au >Subject: Linux Users IDs and NT >Resent-sender: linuxsa-request@linuxsa.org.au >To: linuxsa@linuxsa.org.au >X-Mailer: ELM [version 2.5 PL0pre8] >X-Loop: linuxsa@linuxsa.org.au >X-Mailing-List: archive/latest/2562 >Original-recipient: rfc822;sharpe@ns.aus.com > >Here is one for you samba people out there. > >I have a customer who uses NT as their primary file server. They have >a Web Server running on a Linux Box. > >The intent is that the users can connect to the Web Server and modify >their files through Samba. The system has been added to the Domain, >and the few users that are on the machine authenticate through Samba >to the NT domain. > >The question is... > > Is it possible to synchronise the user names on the web server with > those on the NT domain? I have read of support for 'on the fly' > addition of locked userids to allow the file system access to get > a user id against it. But it isn't clear what 'best practice' is > in this respect. Security in this environment is not paramount, > so locked accounts getting created isn't too much of a problem. > >My guess is that something like a weekly cron job to pick up a username/ >group list to dump on the Linux Server would be appropriate. > >Has anyone done something similar to this? > >Regards, > >Matt > >-- >+----[ Matthew Tippett +61 416 006 047 mtippett@ticons.com.au ]----+ >| Tippett Information Consulting Pty Ltd ]-[ http://www.ticons.com.au/ | >+-----[ Linux and Open Source Development, Consulting and Support ]------+ > >-- >Check out the LinuxSA web pages at http://www.linuxsa.org.au/ >To unsubscribe from the LinuxSA list: > mail linuxsa-request@linuxsa.org.au with "unsubscribe" as the subject > > Regards ------- Richard Sharpe, sharpe@ns.aus.com, NS Computer Software and Services P/L, Samba (Team member www.samba.org), Ethereal (Team member www.zing.org) Co-author, SAMS Teach Yourself Samba in 24 Hours From cartegw at Eng.Auburn.EDU Wed Jun 30 02:51:40 1999 From: cartegw at Eng.Auburn.EDU (Gerald Carter) Date: Tue Dec 2 03:03:10 2003 Subject: Linux Users IDs and NT References: <3.0.5.32.19990630115005.00959d70@mail.adelaide.on.net> Message-ID: <3779863C.BB54809A@eng.auburn.edu> > Is it possible to synchronise the user names on the web server with > those on the NT domain? I have read of support for 'on the fly' > addition of locked userids to allow the file system access to get > a user id against it. But it isn't clear what 'best practice' is > in this respect. Security in this environment is not paramount, > so locked accounts getting created isn't too much of a problem. > > My guess is that something like a weekly cron job to pick > up a username/group list to dump on the Linux Server > would be appropriate. Matt, I wrote three Perl scripts to illustrate this for a chapter in min and Richard's book (chapter 12). You can download the latest version of these via FTP from ftp.eng.auburn.edu/pub/cartegw/samba/domain_member_scripts.tar.gz Let me know if you find them useful or have suggestions for improvement. Cheers, jerry ________________________________________________________________________ Gerald ( Jerry ) Carter Engineering Network Services Auburn University jerry@eng.auburn.edu http://www.eng.auburn.edu/users/cartegw "...a hundred billion castaways looking for a home." - Sting "Message in a Bottle" ( 1979 ) From hedrick at nbcs.rutgers.edu Wed Jun 30 04:06:33 1999 From: hedrick at nbcs.rutgers.edu (Charles Hedrick) Date: Tue Dec 2 03:03:10 2003 Subject: SIGBUS Panic in smbd Message-ID: <377997C8.DC525828@nbcs.rutgers.edu> I've seen a couple of misunderstandings in the posts here. First, the problem is not limited to the getpwanam code. It also happens in the shadow password code. At least with the shadow code, the problem is caused by trying to free the pw_passwd field, with the password hashing code off. Some of the discussion seems to be based on misconceptions of how getpwnam and getspnam work. These functions return pointers to a struct in static memory. Some of the entries in that struct are strings. Those strings are also allocated in static memory. Thus it is invalid to free any of this. There is no problem simply copying the sp_pwdp field from the shadow entry into the pw_passwd field of the normal password struct. sp_pwdp is also a pointer to static memory. One message suggested that somehow doing that copy might reduce a buffer size. That shouldn't be the case. Every time you call getpwnam or getspnam data is put into permanently allocated static space inside the function call. If a previous call has changed the pw_passwd field to point to something small that doesn't matter. The next call to getpwnam will recreate the passwd struct, restoring the pointer to getpwnam's static buffer. (I guess I should say that I'm speaking from knowledge of the way several versions of libc work. It's always possible that someone does it differently. But I strongly doubt it.) As long as the returns from getpwnam are used "soon", i.e. before any further calls to getpwnam, this kind of code is fine. If that's not the case, then you should copy both the struct and all the strings it points to somewhere. If that "somewhere" is malloc'ed then you have to arrange to free it. Another approach is to use the thread-safe versions, e.g. getpwnam_r. (This is on Solaris. I trust Linux also has these.) For these, you pass pointers to the buffers you want it to use. That gives you more control over lifetimes of memory. When I'm writing code that I expect to be called in arbitrary contexts (e.g. functions called by PAM), I always use these calls. I want to make sure I don't overwrite the static buffers if the caller happens to be using one. In retrospect I think that's the approach that should have been used originally, and the traditional one should be phased out. For systems that don't have getpwnam_r, an emulator could be written that calls getpwnam and then copies the data into the buffers supplied by the user to getpwnam_r. I am particularly concerned about having the hashing code under a conditional. The password hash code looks just fine to me. However it uses memory quite differently than when hashing is not in effect. When hashing is off, you're passing around pointers to static memory inside libc. When hashing is on, you're passing around memory that the hash code has malloced and will worry about. That means that the kinds of memory bugs you're going to see in the two cases are very different. Debugging memory allocation is bad enough without two ways to build the program that will produce completely different sets of bugs. I don't care which approach you use (in Solaris the hashing is redundant: the OS does it already), but I strongly recommend that you use only one approach, and do not even provide a conditional to choose between them. From sharpe at ns.aus.com Wed Jun 30 05:14:31 1999 From: sharpe at ns.aus.com (Richard Sharpe) Date: Tue Dec 2 03:03:10 2003 Subject: master browser, os level etc Message-ID: <3.0.5.32.19990630141431.0084e910@mail.adelaide.on.net> Hi, I am confused (again) around the problems that can occur when you have things like os level = 33, preferred master = true etc. Does this confuse clients that think that the domain master browser is in fact the PDC, and thus the logon server? Regards ------- Richard Sharpe, sharpe@ns.aus.com, NS Computer Software and Services P/L, Samba (Team member www.samba.org), Ethereal (Team member www.zing.org) Co-author, SAMS Teach Yourself Samba in 24 Hours From pm at univ-evry.fr Wed Jun 30 06:06:49 1999 From: pm at univ-evry.fr (Pierre MONDIE) Date: Tue Dec 2 03:03:10 2003 Subject: master browser, os level etc In-Reply-To: <3.0.5.32.19990630141431.0084e910@mail.adelaide.on.net> Message-ID: <3.0.6.32.19990630080649.008df5a0@mbox.bp.univ-evry.fr> At 14:41 30/06/99 +1000, Richard Sharpe wrote: >Hi, > >I am confused (again) around the problems that can occur when you have >things like os level = 33, preferred master = true etc. > >Does this confuse clients that think that the domain master browser is in >fact the PDC, and thus the logon server? OS level is used for browser elections only : there are a few interesting articles in MS-KB aka Technet about this -search on the "browser","elections". But there can be a problem if a given Samba server, as a RFC-NBNS, publish bad information about NetBIOS names->IP adresses mapping. Deliberate exploits samples with Perl scripts have been written demonstrating this by Paul ASHTON, if I remember well. -- Pierre MONDIE : SSR : 74-78 From rgooch at atnf.csiro.au Wed Jun 30 07:23:13 1999 From: rgooch at atnf.csiro.au (Richard Gooch) Date: Tue Dec 2 03:03:10 2003 Subject: VFS event hooks in Linux In-Reply-To: <377910BA.7D935061@engr.sgi.com> References: <199906290145.LAA11253@vindaloo.atnf.CSIRO.AU> <199906291424.AAA16991@vindaloo.atnf.CSIRO.AU> <377910BA.7D935061@engr.sgi.com> Message-ID: <199906300723.RAA27074@vindaloo.atnf.CSIRO.AU> Jeremy Allison writes: > Richard Gooch wrote: > > > > Well, I've been talking to Linus about this, and he hates the idea. He > > doesn't like the idea of throwing anonymous events to user space, > > claiming that it's a bad design. > > Well it works for the kernel oplock code :-). What exactly is the oplock code, BTW? > > He suggested that if Samba really needed this information, it might be > > better to put it in kernel space so it can cheaply check the inodes (I > > presume he was referring to avoiding syscall overheads). > > I hope he doesn't mean Samba here. Putting Samba in the kernel > would be a very *bad* idea :-). I doubt he means all of it. But perhaps some general interface that relieves some of the burden off Samba. > > Somehow I doubt that Samba stat()s a large number of files every 60 > > seconds. It would load the system too much. > > No, that's exactly what it has to do to provide close-to-NT > ChangeNotify semantics. It has to scan every directory the client > has expressed an interest in. OK, in a subsequent message you implied that the protocol notifies when file attributes (permissions, I presume?) change somewhere in a directory tree. Is that correct? So is Samba actually stat()ing all files and directories beneath a certain point? I can contemplate stat()ing all directories in a subtree, as that may only be a few hundred inodes. But stat()ing files too would be horrendous, since there are likely to be thousands or tens of thousands of files. > > So I'd like to revist the > > requirements again. What is actually necessary for SMB support? What > > must be done at the server side and what happens at the client side? > > Client opens a directory. Client issues a ChangeNotify request on > directory handle to server. Client request completes when change > occurs (it's a one shot event). So the client blocks, waiting for notification? > > Let me come to this from another direction. Suppose that an SMB server > > need only send directory upate events to clients that have the > > directory open (say in their browser). In that case, it would make > > sense for the SMB protocol to have the server know that a client has > > the directory open. In that case, the VFS poll() patch I've > > implemented for Linux should do fine. You just need one open fd per > > client/browser. > > That works as it is close to the desired semantics (the > server knows the client has a directory open). The problem > is that the NT semantics allow a client to set notification > on a change in a directory *or any subdirectory within it*, > although how many clients actually use that is open to debate > (no one has complained about the current Samba behaviour, which > is only to scan the current directory). Well, if were to only report changes to directory inodes, then it's not so bad, as a few hundred fds is not a major worry. OK, so Samba is only reporting on inode write events for the directory and its leaf nodes (including regular files)? Well, that's relatively cheap, as you're only looking at a few dozen files at most (typical usage). The new poll()-based scheme I've implemented will handle this easily. So if Samba is cheating, we can at least make such cheating efficient on Linux :-) A separate question is can we stop cheating and pass the Linus barrier? ;-) Regards, Richard.... From rgooch at atnf.csiro.au Wed Jun 30 07:33:37 1999 From: rgooch at atnf.csiro.au (Richard Gooch) Date: Tue Dec 2 03:03:10 2003 Subject: VFS event hooks in Linux In-Reply-To: References: <199906291424.AAA16991@vindaloo.atnf.CSIRO.AU> Message-ID: <199906300733.RAA27122@vindaloo.atnf.CSIRO.AU> Greg Dickie writes: > This is REALLY not my area of expertise but I'm sure Jeremy will > know more about this. IRIX has a thing called a FAM (File alteration > monitor) which I believe has a similar function to what you are > looking for. Perhaps you could mimic that mechanism and it would be > enough? I've had a look at this, but it basically implies that the kernel has to keep all "interesting" inodes in its inode cache. In the case of a subtree, that can be a lot of inodes (because apparently files as well as directories need to be watched for SMB). Say I wanted to export my /usr. I've got nearly 24000 inodes there. If a client was dumb enough to request a ChangeNotify event directly under /usr, Samba would have to register 24000 inodes with /dev/imon. Firstly Samba would have to recursively scan /usr finding all inodes, and register each one with /dev/imon. 1+ syscalls per inode! Then the kernel would have to cache each inode. Let's say 128 bytes per inode. We're looking at 3 MiBytes of inode cache, clagging up RAM. Yuk. I suppose memory is cheap these days, but still that feels too much to me. The word "scalability" doesn't come to mind... Regards, Richard.... From robert at vps.co.za Wed Jun 30 09:01:27 1999 From: robert at vps.co.za (Robert Sandilands) Date: Tue Dec 2 03:03:10 2003 Subject: VFS event hooks in Linux In-Reply-To: <199906291424.AAA16991@vindaloo.atnf.CSIRO.AU> Message-ID: On Wed, 30 Jun 1999, Richard Gooch wrote: > Robert Sandilands writes: > > > > On Tue, 29 Jun 1999, Richard Gooch wrote: > > > > If I understand correctly it would be very slow. The type of message > > generated needs to be processed as quickly as possible. So having to > > walk trees etc. is not the best idea when performance is an issue. > > Actually, walking up the directory entry (dentry) tree would be fairly > fast. The Linux dentry mechanism is extremely fast. The killer would > be if the client then scans a large part of the tree. I'm a pessimist, always work on worst case scenarios... Doing lost of very fast things end up being slow... And with this type of thing speed is very important... > > The idea of making it per-FS is a good idea. > > Well, I've been talking to Linus about this, and he hates the idea. He > doesn't like the idea of throwing anonymous events to user space, > claiming that it's a bad design. He is right... But you have to make a compromise between what is good design and what is speed-efficient code. I know it is a Microsoft attitude but we will hopefully make certain it works all the time and not only some of the time :-) > However, putting it in the kernel wouldn't help since many inodes in a > directory tree wouldn't be in the inode cache anyway. So the real > limit is the disc I/O on countless thousands of inode lookups. Why do you want to do thousands of inode lookups ? The cost would be horendous no matter how fast a single lookup happens. You would be doing a huge amount of them every second. > Somehow I doubt that Samba stat()s a large number of files every 60 > seconds. It would load the system too much. So I'd like to revist the > requirements again. What is actually necessary for SMB support? What > must be done at the server side and what happens at the client side? I'm talking from a slightly selfish point of view here... I would like to be able to implement on-access scanning of samba shares.. For that I need to know whenever a file is created, opened and/or closed. This would be a hook implemented into samba itself or into the kernel ? This will happen on the file-serving machine. > Let me come to this from another direction. Suppose that an SMB server > need only send directory upate events to clients that have the > directory open (say in their browser). In that case, it would make > sense for the SMB protocol to have the server know that a client has > the directory open. In that case, the VFS poll() patch I've > implemented for Linux should do fine. You just need one open fd per > client/browser. For this type of application the directory only needs to be updated for every client about once a minute or whenever the client requests a refresh. Speed requirements here would not be important and only the fact that a change occured is needed, not what the change was. _________________________________________________________________________ Silly little things like representing anybody else is not of importance ------------------------------------------------------------------------- Robert Sandilands - Peace is when the music of the soul harmonizes with the music of Life Tel: +27-12-841-2106, Fax: +27-12-841-4670, Email: robert@vps.co.za ------------------------------------------------------------------------- From weave at hopi.dtcc.edu Wed Jun 30 10:41:20 1999 From: weave at hopi.dtcc.edu (Ken Weaverling) Date: Tue Dec 2 03:03:10 2003 Subject: SV: SIGBUS Panic in smbd In-Reply-To: <014901bec200$4ee0daa0$0300a8c0@emil.pgmt> Message-ID: > > I still cannot see why this thing is crashing Ken's > > system, unless the underlying passwd functions are > > keeping a private malloced area that they are doing > > a free() on on second and subsequent calls.... > > That could be, and since we don't know and it could be different > between different systems, we shouldn't free the pointers or reassign > them to either static or allocated memory (they are owned by the > library, not us). I do still propose strcpy as the dirty hack and a > struct of our own as the fix. The man page for getpwnam on DG/UX says: BUGS In all of the above functions except getpwent_r, getpwuid_r, getpwnam_r, and fgetpwent_r, the information is contained in a static area, so it must be copied if it is to be saved. However, the stack trace of my core files consistently show getpwnam being called, and triggering a malloc or realloc, so "static" is obviously not to be taken literally in this case... I think perhaps some of this might be due to NIS functions being called in the background on our box. My programmer (a far better code hacker than I), Luke Brown (luke@hopi.dtcc.edu), tells me that he had some serious problems with getpwnam_r not being thread safe in a program he wrote using threads on DG/UX due to the NIS crap. He ended up rewriting it to be thread safe. So he can rewrite me a getpwnam() call that REALLY uses a static ptr if need be and hopefully our libc won't freak if a free to an unknown pointer happens. This is a hack, but it can at least save us if/until y'all fix the code! > > Ken - do you have purify on that box ? No, 'fraid not. I don't even have strace... :-( > This would be an almost good approach, but quite unmanagable I think > (for the same reason I think that getpwnam and getpwanam deals in > static memory, it is virtually impossible to know when to free/reset > the pointers unless you make a function for that which must be called > when we're done with the struct). Thanks for the help. I have 13,000 users on my quad-processor DG/UX boxes (although not all at once, usually just a few hundred at once). It was only panic'ing with me for some reason, and only my account and not others on my same client. But yesterday I saw a panic occur to another user, so it's a rare trigger, but not isolated. -- Ken Weaverling (weave @ dtcc.edu) WHOIS: KJW Manager of Computer Support and Applications Delaware Technical & Community College From firebird at janus.syracuse.net Wed Jun 30 21:58:10 1999 From: firebird at janus.syracuse.net (firebird) Date: Tue Dec 2 03:03:10 2003 Subject: automount and windows explorer In-Reply-To: <3779863C.BB54809A@eng.auburn.edu> Message-ID: Hello all, I am getting a rather strange behavior when trying use automount with samba. I have a solaris 2.6 box running samba 2.0.4b. It automounts home directory from all over the place, and we have about ~100s for home directories. As most of you know, with Solaris 2.6, the direcotries that are "automountable" can be seen when an user does an "ls" in the parent dir. In other words: if i had auto.home with 300 home dirs to be mounted under /home/, and if i were to do an "ls" under /home, on a solaris 2.6, i would be able to see all this possible mount points. That part works okay. Now, what i am trying to do is have these home directories appear as a share on the NT side. I would like to do something like this: [homes] guest ok = no read only = no path = /home So, that when a user logs in, he is locked to /home. What i expected is to get a list (and ONLY a list) of "auto-mountable" directories (which would be mounted upon double clicking the directory in windows explorer). However, it appears as if windows explorer is scanning sub-directories and it start mounting all 300 mount points. What is needed is to be able to see the data, do the mount only upon request. I was hoping the new feature of automount under solaris 2.6 would help to be able to "list" the directories in explorer. Any comments, suggestions? I would appriciate input from others who have worked with a combination of samba and automount. thank you.