Re: ??????: ???`: ??????: When the keep-alive packet sentout,rfc1002 says different things!!
On Tue, Apr 01, 2003 at 06:01:54PM +0800, [EMAIL PROTECTED] wrote: : > Ethereal is recommended, if only because the rest of us know how to read > it... > > ^^ Thanks, I will download it and try.Is it more powerful than NAI >sniffer? NAI sniffer will treat a packet simply beginning with >0x85 as keep-alive, an obvious bug:) I have no idea, since I know nothing about the NAI sniffer. What I do know is that there are some very bright Samba folk committing code to the Ethereal project. > When they receive an *NBT* packet. The NBT keepalive timer is managed at > the NBT layer. The TCP stream won't reset the timer, but the initial READ > RAW request *should* reset the timer. > > But I think raw data is also an NBT packet, which is passed > through to user layer. Ah... No, it's not! :) These are layered protocols. The entire READ RAW is considered one SMB 'message'. Each SMB message is packed within a single NBT Session Service wrapper (which is just the header). > So, server is responsible to reset the timer anyway. And the read raw > request, doesn't reset timer either, as I have seen, just between > two read request, keep-alive occurs. The way it *should* work is that the initial request (the READ RAW request or the WRITE RAW request) should reset the timer. Even if that didn't happen, the READ/WRITE RAW response *should* complete before the server sends any keep-alives. What I *think* you are saying is that neither of those things happen. Again, I have trouble imagining it, but I'm certainly willing to look at a capture. > I really can't imagine Samba making the mistake of sending the keep-alive > while it is in the middle of a READ RAW operation, but I would believe it > if I saw a capture that shows it (an Ethereal capture would be > best...www.ethereal.com...it's free). > > ^^^ I really don't see this too. What I have seen is that keep-alive > appends to the head of response or a seperate keep-alive packet. > But I have no evidence that it will NOT be sent out during raw data > stream,especially in a mutithread environment. Hmmm... A keep-alive before or after the READ/WRITE RAW is perfectly okay. The keep-alives are part of the NBT layer, not the SMB layer, and may show up asynchronously. They *should*, however, show up before or after another NBT message...definitely not in the middle. I understand your concern, but unless there is evidence of a keep-alive showing up inside another NBT message I wouldn't worry about it. > ^^^ And I find a way,in windows, there is a registry key controlling > sessionkeepalive(it just name of it) So, I can switch it off then > none of keep-alive can be sent out any more.If no other safer > solution, I will do it this way. That's not a safe solution, since you won't have control over the server once you release your client software. Good luck! Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
Realization re UDP138 and the Browse Service
Just a note... something I figured out while working on my book. There was a complaint a while back (a long while, possibly) that the datagram service--the MSBrowse Protocol in particular--did not respond to the correct port. If, for example, a client opens a high-numbered UDP port to send a GetBackupListRequest the GetBackupListResponse is sent to port 138, even though that's not the source port of the original Request. Turns out that this is correct behavior. Yes, really. See, the problem is that the mailslot protocol is not a two-way protocol. It's all one-way. There are no "replies" in the traditional sense. It's more like stimulus-response. Mailslot functions generate a mailslot message... and that's it. End of story. The fact that the original message illicits a reaction from some other node is secondary. The response is also a mailslot message, so it gets sent to port 138. Weird, yes. Still, that seems to be the way it was designed. Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
Re: Problems with ACLs in 2.2.8
On Tue, Apr 01, 2003 at 02:54:27PM +0200, Michael Steffens wrote:
> From my understanding Samba has no other choice than inserting missing
> object ACEs, because it's impossible to set a POSIX ACL without. The
> crucial point not being whether, but what to insert. What does the
> client intend when sending an ACL without object entries?
sorry. i should have guessed there was some Windows idiosyncracy you
all were working around before i went and #if-ed out all your code.
since i haven't been using samba with MS Office running on Win2k, i
can't comment on your findings, so i should probably bow out, but
for those of us who are fortunate enough to be using platforms that
don't have the savvy to reset ACLs brokenly when creating temp files,
it'd be nice if there was an option not to have the Win2k workaround
foisting permissions on us we're trying to get rid of. e.g., can the
current_posix_acl stuff be skipped if nt4_compatible_acls()?
that all said, i think this bit is incorrect:
if (setting_acl) {
if (got_current_grp) {
pace->perms = current_grp_perms;
} else {
/* If we only got an "everyone" perm, * just use that.
*/
if (got_other)
pace->perms = pace_other->perms;
else
pace->perms =
unix_perms_to_acl_perms(pst->st_mode, S_IRGRP, S_IWGRP, S_IXGRP);
}
apply_default_perms(fsp, pace, S_IRGRP);
} else {
pace->perms =
unix_perms_to_acl_perms(pst->st_mode, S_IRGRP, S_IWGRP, S_IXGRP);
}
i.e., in the fall-through case there, rather than assigning the result
of unix_perms_to_acl_perms(), it should be zero, just like the default
for the user perm (not shown), although you'll almost certainly always
have got_current_grp
sorry to rant. i appreciate you guys have a rough go of it, trying to
keep pace with Microsoft's ``innovations'' like half-a*ed ACLs, so i'm
really grateful and thank you
RE: Users able to execute windows .exe though execute bit not set
Perhaps you're thinking of the setuid/setgid/sticky bits. This is why I referred the question to Jeremy Allison. He (literally) wrote the book on this. I'd quote from his CIFS presentation, but I can't find it online, and I don't have my copy with me. There should also be some consideration of the security implications. If someone can use a Windows mount to push a file onto a Unix server, and get it's execute and setuid bits set, they could run the program as the Unix user who writes files on the share. It may not be much of a hole, but it is one. This is why I think there should be no mapping between Windows and Unix, and only an ACL which controls execute permission for Windows. The functionality would be there for both systems, but neither could easily affect the other. -Original Message- From: David Brodbeck [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 3:48 PM To: 'Jim McDonough'; Esh, Andrew Cc: John H Terpstra; [EMAIL PROTECTED]; Nick Drouet; [EMAIL PROTECTED] Subject: RE: Users able to execute windows .exe though execute bit not set > -Original Message- > From: Jim McDonough [mailto:[EMAIL PROTECTED] > The unix "x" bit is a perfectly > reasonable place to > store this, and unix has the same problems windows does...if > you can read > it, you can copy it and change the bits in your own copy. Isn't the UNIX "x" bit already taken? I thought it was being used to map one of the other DOS mode bits.
RE: Users able to execute windows .exe though execute bit not set
> -Original Message- > From: Jim McDonough [mailto:[EMAIL PROTECTED] > The unix "x" bit is a perfectly > reasonable place to > store this, and unix has the same problems windows does...if > you can read > it, you can copy it and change the bits in your own copy. Isn't the UNIX "x" bit already taken? I thought it was being used to map one of the other DOS mode bits.
rpc client timeouts
I'm having the following problem with Samba 3.0-alpha22, AIX and winbind. Whenever winbind is queried for information about certain groups, like Domain Users, it fails to return any data and produces the following log message: rpc_client/cli_pipe.c:rpc_api_pipe(359) cli_pipe: return critical error. Error was Call timed out: server did not respond after 1 milliseconds as well as others. My conjecture about the cause of the problem is this: We have a rather large domain, 64,047 users according to wbinfo. Returning the group entry implies fetching and returning the list of group members. Winbind calls into the rpc client, which starts fetching the list of members The rpc client sets a timeout and starts pulling the list of group members Fetching all 60k users takes longer than the timeout, the timeout fires and the rpc client returns failure I'm hoping that the solution is either: The rpc client timeout can be made smarter, it could check if any data had been received before it failed the request, or, I can statically increase the timeout somewhere until the problem goes away Thanks in advance -Steve
RE: Users able to execute windows .exe though execute bit not set
>What is Windows is using to determine that it needs to do the >"executability" test? There is no executable bit in Windows. There is the >ACL entry, but nothing at the DOS level. That is, unless they are testing >the file extension. It uses the ACL. It follows locally what's in the ACL, and the server will grant/deny the requested access based on what's in the ACL. It works. Folks have pointed out that you can just get around it by reading the file, copying it locally, and running it from there, but there are many companies out there that lock down all the workstations, and prevent local write access for this very reason. >What Windows would need is a marker that enables a file for execution, and a >network request from the client which notifies the server that the file is >being read for execution. Windows could compare the two, and deny the read >if the file is not enabled. In any case, it has to trust the client not to >read the file for non-execution, and then execute it. Since Windows is also >the client, such a trustworthiness can be relied upon. The ACL is this marker, and the network request NTCreateX will pass along whatever access you tell it, and windows clients tell it they want "execute" access. I detail the trust situation above. >I would not be surprised to learn that Samba does not do the "executable" >test on files being read, since there is no reasonable place to store a >Windows execution flag. (Perhaps this can be added as an extended attribute >setting.) If Windows is testing the file extension instead, then Samba >should be extended to do the same thing. Samba does not test any of the bits, but rather relies on the OS to do the testing. This works fine for read and write, because open() allows you to specify them. You can't request "X' permissions, though, so we'd have to explictly test it. The unix "x" bit is a perfectly reasonable place to store this, and unix has the same problems windows does...if you can read it, you can copy it and change the bits in your own copy. Jim McDonough IBM Linux Technology Center Samba Team 6 Minuteman Drive Scarborough, ME 04074 USA [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984
Document updates
Folks, I am updating the Samba documentation in the HEAD and 3.0.0 branches today. If anyone has either documentation notes that they wish to contribute _or_ has constructive comments please email them to me direct at [EMAIL PROTECTED] as soon as you can. Later today (in about 5 hours time) I will commit my changes and want that to be my last hit at this for a while. So if you have anything you would like to see added NOW IS THE TIME. :) - John T. -- John H Terpstra Email: [EMAIL PROTECTED]
RE: Users able to execute windows .exe though execute bit not set
What is Windows is using to determine that it needs to do the "executability" test? There is no executable bit in Windows. There is the ACL entry, but nothing at the DOS level. That is, unless they are testing the file extension. What Windows would need is a marker that enables a file for execution, and a network request from the client which notifies the server that the file is being read for execution. Windows could compare the two, and deny the read if the file is not enabled. In any case, it has to trust the client not to read the file for non-execution, and then execute it. Since Windows is also the client, such a trustworthiness can be relied upon. I would not be surprised to learn that Samba does not do the "executable" test on files being read, since there is no reasonable place to store a Windows execution flag. (Perhaps this can be added as an extended attribute setting.) If Windows is testing the file extension instead, then Samba should be extended to do the same thing. -Original Message- From: Jim McDonough [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 12:03 PM To: John H Terpstra Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Nick Drouet Subject: Re: Users able to execute windows .exe though execute bit not set >Perhaps you can explain how you would achieve your goals if the server was >running Windows 2000 Server. If you can demonstrate a pure Windows >solution maybe we could match that with Samba. John, I've checked it out and this is a real difference between Samba and NT or 2k. NT/2k both check the X permission, and we don't, because we rely on open(), and you can't request X access on open()... Jim McDonough IBM Linux Technology Center Samba Team 6 Minuteman Drive Scarborough, ME 04074 USA [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984
net rpc info returns incorrect information for Mixed Mode ADS domains
Hello list, On a recent checkout of and compile of HEAD, I notice that net rpc info -S IP does not show the correct number of Local and Global groups for Mixed Mode ADS domains: For a Mixed Mode ADS domain: Domain Name: HERCULES Domain SID: S-1-5-21-2719260386-3042169546-4001689493 Sequence number: 50997 Num users: 32 Num domain groups: 0 Num local groups: 14 In actuality, there are 7 users, 7 Domain Local Groups, 9 Builtin Local Groups and 14 Global groups. So the output of the net rpc info command is very wrong. Here is a net rpc info against an NT4 domain: [2003/04/01 11:18:30, 1] libsmb/cliconnect.c:cli_full_connection(1226) session request to 10.33.1.23 failed (Called name not present) Domain Name: MORIA Domain SID: S-1-5-21-1613054590-870150751-2064540314 Sequence number: 12046 Num users: 105 Num domain groups: 209 Num local groups: 2 The number of users, domain groups, and local groups are all accurate here. This is easy to reproduce, just run net rpc info against a Mixed Mode ADS domain. -Marc
RE: Users able to execute windows .exe though execute bit not set
You should note that the ACL system and the Unix permission bits are two different things. What you are actually talking about is the translation between the two. If the ACL system has Execute permission set for the user, then that user should be able to execute the program on the client. That determination is made on the client end. If the Unix execute bit is set, then a Unix user should be able to run that executable on the Unix host. My personal opinion is that there is no meaningful translation between the two, unless we are talking about Perl scripts, or something else which runs on both systems. If there is an ACL system as part of the server, I don't see any need to bother with the Unix execute bits, for Windows-only executables. The problem is compounded by the possibility that those bits have been used within Samba to store other functionality such as the DOS System or Hidden bits. Jeremy Allison is the one who can state this case better than I can. He gave a presentation at the CIFS conference in Bellevue, in August 2001 on this very subject. He should make the final determination on this. -Original Message- From: Ronan Waide [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 11:23 AM To: Richard Sharpe Cc: [EMAIL PROTECTED]; Nick Drouet Subject: Re: Users able to execute windows .exe though execute bit not set On April 1, [EMAIL PROTECTED] said: > > Hmmm, I did some testing a week or so ago, and found that removing the > execute permission from ACLs on the file (esp inherited ones) prevents > Win2K from executing the file, although it does open the file for read > first. Yep, turns out I opened my mouth without being completely sure of what I was saying :) > Since we have just added proper eXecute permission support to our (almost) > NT ACLs in the file system, let me check this today to see what the deal > is. jmcd says it should work. Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. "for god's sake, give me some credit. i may be an egocentric jerk, but i'm not a COMPLETE asshole." - Meredith
Re: Users able to execute windows .exe though execute bit not set
On Tue, 1 Apr 2003, Jim McDonough wrote: > >Hmmm, I did some testing a week or so ago, and found that removing the > >execute permission from ACLs on the file (esp inherited ones) prevents > >Win2K from executing the file, although it does open the file for read > >first. > Doesn't happen for me. It lets me execute a file for which I only have > read access... Right, but I was testing Win2K against NT. I know that we will fail this test, as discussed on IRC because the POSIX open call does not allow you to specify O_EXEC ... so I will need to do other checks here. However, since our NFS code needs to check for X access, I can probably piggy back on this with an IOCTL. UGLY. We should probably have a torture test for this. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: Users able to execute windows .exe though execute bit not set
>Perhaps you can explain how you would achieve your goals if the server was >running Windows 2000 Server. If you can demonstrate a pure Windows >solution maybe we could match that with Samba. John, I've checked it out and this is a real difference between Samba and NT or 2k. NT/2k both check the X permission, and we don't, because we rely on open(), and you can't request X access on open()... Jim McDonough IBM Linux Technology Center Samba Team 6 Minuteman Drive Scarborough, ME 04074 USA [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984
RE: Users able to execute windows .exe though execute bit not set
Just to add fuel to the fire... for me as well, Execute has no bearing on execution of files via Samba. It does have the normal UNIX meaning on directories though. -Original Message- From: Jim McDonough [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 9:57 AM To: Richard Sharpe Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Nick Drouet Subject: Re: Users able to execute windows .exe though execute bit not set >Hmmm, I did some testing a week or so ago, and found that removing the >execute permission from ACLs on the file (esp inherited ones) prevents >Win2K from executing the file, although it does open the file for read >first. Doesn't happen for me. It lets me execute a file for which I only have read access... Jim McDonough IBM Linux Technology Center Samba Team 6 Minuteman Drive Scarborough, ME 04074 USA [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984
Re: Users able to execute windows .exe though execute bit not set
>Hmmm, I did some testing a week or so ago, and found that removing the >execute permission from ACLs on the file (esp inherited ones) prevents >Win2K from executing the file, although it does open the file for read >first. Doesn't happen for me. It lets me execute a file for which I only have read access... Jim McDonough IBM Linux Technology Center Samba Team 6 Minuteman Drive Scarborough, ME 04074 USA [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984
printing problem alpha 23
Hi guys! After upgrading from alpha22 to alpha23, I immediately started having printing problems. After looking to the logs, I was able to find that something definitely changed. Maybe some files moved to another place? Can you take a look? In my /var/log/messages file this poped up: Apr 1 18:13:00 aulas smbd[16605]: [2003/04/01 18:13:00, 0] passdb/pdb_smbpasswd .c:startsmbfilepwent(189) Apr 1 18:13:00 aulas smbd[16605]: startsmbfilepwent_internal: unable to open file /etc/samba/smbpasswd. Error was No such file or directory Apr 1 18:13:00 aulas smbd[16605]: [2003/04/01 18:13:00, 0] passdb/pdb_smbpasswd .c:smbpasswd_getsampwnam(1350) Apr 1 18:13:00 aulas smbd[16605]: unable to open passdb database. Apr 1 18:13:01 aulas smbd[16605]: [2003/04/01 18:13:01, 0] lib/fault.c:fault_re port(36) Apr 1 18:13:01 aulas smbd[16605]: === Apr 1 18:13:01 aulas smbd[16605]: [2003/04/01 18:13:01, 0] lib/fault.c:fault_re port(37) Apr 1 18:13:01 aulas smbd[16605]: INTERNAL ERROR: Signal 11 in pid 16605 (3.0 alpha23) Apr 1 18:13:01 aulas smbd[16605]: Please read the file BUGS.txt in the distri bution Apr 1 18:13:01 aulas smbd[16605]: [2003/04/01 18:13:01, 0] lib/fault.c:fault_re port(39) Apr 1 18:13:01 aulas smbd[16605]: === Apr 1 18:13:01 aulas smbd[16605]: [2003/04/01 18:13:01, 0] lib/util.c:smb_panic (1429) Apr 1 18:13:01 aulas smbd[16605]: PANIC: internal error Apr 1 18:13:01 aulas smbd[16605]: Apr 1 18:13:01 aulas smbd[16608]: [2003/04/01 18:13:01, 0] passdb/pdb_smbpasswd .c:startsmbfilepwent(189) Apr 1 18:13:01 aulas smbd[16608]: startsmbfilepwent_internal: unable to open file /etc/samba/smbpasswd. Error was No such file or directory Apr 1 18:13:01 aulas smbd[16608]: [2003/04/01 18:13:01, 0] passdb/pdb_smbpasswd .c:smbpasswd_getsampwnam(1350) Apr 1 18:13:01 aulas smbd[16608]: unable to open passdb database. Apr 1 18:17:46 aulas nmbd[16596]: [2003/04/01 18:17:46, 0] nmbd/nmbd_namequery. c:query_name_response(111) Apr 1 18:17:46 aulas nmbd[16596]: query_name_response: Multiple (2) responses received for a query on subnet 192.168.1.11 for name PORTO<1d>. Apr 1 18:17:46 aulas nmbd[16596]: This response was from IP 192.168.1.150, re porting an IP address of 192.168.1.150.
Re: Users able to execute windows .exe though execute bit not set
On April 1, [EMAIL PROTECTED] said: > > Hmmm, I did some testing a week or so ago, and found that removing the > execute permission from ACLs on the file (esp inherited ones) prevents > Win2K from executing the file, although it does open the file for read > first. Yep, turns out I opened my mouth without being completely sure of what I was saying :) > Since we have just added proper eXecute permission support to our (almost) > NT ACLs in the file system, let me check this today to see what the deal > is. jmcd says it should work. Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. "for god's sake, give me some credit. i may be an egocentric jerk, but i'm not a COMPLETE asshole." - Meredith
Re: Users able to execute windows .exe though execute bit not set
On Tue, 1 Apr 2003, Ronan Waide wrote: > On April 1, [EMAIL PROTECTED] said: > > I'm looking for some assistance regarding file permissions and the inability > > to stop the execution of a file even though the execute permission has not > > been set. > > Execute bits are a Unix concept. Windows will execute any file it can > read that it understands the extension of and has a handler for. Hmmm, I did some testing a week or so ago, and found that removing the execute permission from ACLs on the file (esp inherited ones) prevents Win2K from executing the file, although it does open the file for read first. Since we have just added proper eXecute permission support to our (almost) NT ACLs in the file system, let me check this today to see what the deal is. Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
RE: tmp files hanging around too long.
Oops, Brad; sorry - just noticed this is on 3.0; my problem is at 2.2.5 on HPUX with the "map share modes" parameter, not the 'share modes' parameter. Don > -Original Message- > From: Bradley W. Langhorst [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 01, 2003 11:37 > To: MCCALL,DON (HP-USA,ex1) > Cc: [EMAIL PROTECTED] > Subject: RE: tmp files hanging around too long. > > > On Tue, 2003-04-01 at 10:19, MCCALL,DON (HP-USA,ex1) wrote: > > Hi Brad, > > We have noticed an extra open on files when you > > have 'map share modes = yes' in the smb.conf file; > > This causes a problem with deleting a file that you > > own IF the unix permissions are 0700. At least that's the > > symptom that came in for us; perhaps your tmp file issue is > > related. > > Can you do a testparm and see how that parameter > > is set on your system? > testparm -v shows > share modes = Yes > > i also have oplocks turned off for this share - maybe that's a > problem... > > I'll mess with both settings later today... > > brad > -- > Bradley W. Langhorst <[EMAIL PROTECTED]> >
RE: tmp files hanging around too long.
On Tue, 2003-04-01 at 10:19, MCCALL,DON (HP-USA,ex1) wrote: > Hi Brad, > We have noticed an extra open on files when you > have 'map share modes = yes' in the smb.conf file; > This causes a problem with deleting a file that you > own IF the unix permissions are 0700. At least that's the > symptom that came in for us; perhaps your tmp file issue is > related. > Can you do a testparm and see how that parameter > is set on your system? testparm -v shows share modes = Yes i also have oplocks turned off for this share - maybe that's a problem... I'll mess with both settings later today... brad -- Bradley W. Langhorst <[EMAIL PROTECTED]>
HEAD smbclient/smbtar problem
[EMAIL PROTECTED] source]# smbclient //server/print\$ -U admin%passwd -Tc Error opening local file //server/print$ - No such file or directory It's picking up the share name as the tar file name. Even specifying a filename after -Tc doesn't work. Sneaking tar.out in as the first parameter doesn't fix things either as Samba then tries to parse that as a share name. Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. "my head is full of songs I don't like, with lyrics about things you've said." - Veep
Re: Users able to execute windows .exe though execute bit not set
Nick, Perhaps you can explain how you would achieve your goals if the server was running Windows 2000 Server. If you can demonstrate a pure Windows solution maybe we could match that with Samba. - John T. On Tue, 1 Apr 2003, Nick Drouet wrote: > I'm looking for some assistance regarding file permissions and the inability > to stop the execution of a file even though the execute permission has not > been set. > > Scenario > > I create a share. > I copy the notepad.exe from a windows client onto the share. > > >From Linux console: > > chown notepad.exe > chmod 600 notepad.exe > > >From Windows client: > > I map a drive to the share and I am still able to run the notepad.exe file > from the share, even though executable permissions aren't set... > > I can remove the executable flag via the Windows GUI and the same occurs. > I've tried other executable files and the same occurs. If I chmod 222 to > remove any read rights, then I get the access denied that I would expect. > > > As far as user permissions are going, I've tried a number of options. > Originally I had a samba server as a member of a Windows NT Domain, using > Winbind to map user IDs. This also had ACL support with the 2.4.17acl kernel > and permissions were being set fine on multiple users from the NT domain. > I've stripped elements out until I now have just a samba server which is not > part of a domain and my windows user is in the smbpasswd file with matching > user Id and password. At all stages this problem occurs. I need to know if > I'm doing something very dumb here but the ability to stop users running > executables from a network share is critical. > > Clients are Windows 2000 / NT4 > Samba versions that I've tried are 2.2.8 and 2.0.0.15 (RPM from SuSE > installation CD). > Linux distros that I've tried are SuSE 7.2 and Redhat 7.2 > > Does anyone have any light they could throw onto why this is happening? > > I've seen a few threads regarding this in the samba general but no replies > so forgive if off topic slightly but could really do with some hints.. > > Relevant bits from my smb.conf are below. > > > > [global] >workgroup = DOMAIN2 >guest account = nobody >keep alive = 30 >os level = 2 >kernel oplocks = false >security = domain >encrypt passwords = yes >socket options = TCP_NODELAY >map to guest = Bad User >wins server = 192.168.1.80 >netbios name = samba1 >winbind uid = 1000-2000 >winbind gid = 1000-2000 >winbind cache time = 10 >winbind separator = + >password server = * >log file = /var/log/samba >log level = 1 > > [share3] >path = /share3 >comment = shared area >read only = no >browseable = yes > > > > > -- John H Terpstra Email: [EMAIL PROTECTED]
RE: Request - security patch for 2.0.6
what is the difficulty upgrading in your environment, just curios -Original Message- From: dowlime [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 1:15 PM To: [EMAIL PROTECTED] Subject: Request - security patch for 2.0.6 Is there a plan for a patch for 2.0.6 to address the security bug announced 3/14/03? If not, I am requesting such a patch, as upgrading to 2.2.8 will cause difficulty in our environment. (the "Take Ownership" overloading no longer works in 2.2.8, so emply ACE's don';t show up in the permission dialog in NT) The release notes for 2.2.8 says "As this is a security issue, patches for this flaw specific to earlier versions of Samba will be posted on the [EMAIL PROTECTED] mailing list as requested."
Authentication through Transitive Trusts
Samba-folk: I have an Active Directory with SUPTRA at the top and 2 other AD servers, KAMA and CAMP. If Samba joins KAMA, it can authenticate against KAMA and/or SUPTRA, but not CAMP. wbinfo -u shows users from all 3 servers, but wbinfo -m only shows SUPTRA. KAMA and CAMP have an implicit transitive trust, but I can't seem to get Samba to use it. The authentication request is sent to KAMA, but it gets NT_STATUS_NO_SUCH_USER. (Same results if it joins CAMP and tries to authenticate against KAMA.) Is there some trick to using transitive trusts (SAMBA_3_0)? Ken Ken Cross Network Storage Solutions Phone 865.675.4070 ext 31 [EMAIL PROTECTED]
RE: FW: encrypt passwords=no, security=yes, samba 2.2.8, W2K useraut h fails
Hi Dave, yeah, not pretty - should be fixed in the code. Just looking for a workaround that might be less undesireable than security = share (which was one of the options he was looking at in a private message to me). The point really is that we shouldn't even be LOOKING in the smbpasswd file when we specify encrypt passwords = no. But until we fix that, moving his users (from whatever user store he is using, nis, etc/passwd, etc) into the smbpasswd file, will avoid this particular windowsism. And with encrypt passwords = no, the smbpasswd is NOT being used for authentication, just verification of user existence for the 'map to guest=bad user' case... It's very convoluted code... not pretending to understand it all. (grin) That's why I cc'ed the list on the original problem and a (possibly poor) code diff change to fix it... Hopefully someone will look at that and say - well, HEY, that's dumb - lets fix it THIS way... Don > -Original Message- > From: David Collier-Brown -- Customer Engineering > [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 01, 2003 10:34 > To: MCCALL,DON (HP-USA,ex1); '[EMAIL PROTECTED]' > Subject: Re: FW: encrypt passwords=no, security=yes, samba 2.2.8, W2K > user aut h fails > > > That's highly undesirable, as it breaks single-signon > (unless you're an NT-cenric organization, which Sun isn't (:-)) > > --dave > > |Hi Tony, > |Another workaround would be to populate an smbpasswd file > with all the names > | > |from your /etc/passwd file. > |But I realize this can be onerous. Samba has a script to > help with this, > |mksmbpasswd.sh > |since you won't be needing passwords from this smbpasswd > file, this would do > |it for you, I think if your distribution doesn't > install this script, > |it > |can be found in the source at > /usr/local/samba/source/script/mksmbpasswd.sh > | > |useage: > | > |cat /etc/passwd|./mksmbpasswd.sh > >/usr/local/samba/var/private/smbpasswd > | > |Hope this helps > |Don > >
Re: FW: encrypt passwords=no, security=yes, samba 2.2.8, W2K useraut h fails
That's highly undesirable, as it breaks single-signon (unless you're an NT-cenric organization, which Sun isn't (:-)) --dave |Hi Tony, |Another workaround would be to populate an smbpasswd file with all the names | |from your /etc/passwd file. |But I realize this can be onerous. Samba has a script to help with this, |mksmbpasswd.sh |since you won't be needing passwords from this smbpasswd file, this would do |it for you, I think if your distribution doesn't install this script, |it |can be found in the source at /usr/local/samba/source/script/mksmbpasswd.sh | |useage: | |cat /etc/passwd|./mksmbpasswd.sh >/usr/local/samba/var/private/smbpasswd | |Hope this helps |Don
RE: tmp files hanging around too long.
Hi Brad, We have noticed an extra open on files when you have 'map share modes = yes' in the smb.conf file; This causes a problem with deleting a file that you own IF the unix permissions are 0700. At least that's the symptom that came in for us; perhaps your tmp file issue is related. Can you do a testparm and see how that parameter is set on your system? Thanks, Don > -Original Message- > From: Bradley W. Langhorst [mailto:[EMAIL PROTECTED] > Sent: Friday, March 28, 2003 15:51 > To: [EMAIL PROTECTED] > Subject: tmp files hanging around too long. > > > I recently upgraded my a21 system to a22 > runaway smbds seem to have disappeared. > > A new, less serious problem, has emerged. > > When a user keeps a word document open for a very long time i see a > proliferation of locked temporary files (87 since yesterday) > > I'd like to help track down this problem but I'm not sure where to > start... > > The logs show the the tmp files are opened and > opened > closed > opened > closed > opened > closed > opened > closed > opened > opened > closed > closed > opened > closed > opened > opened > closed > > note that the last closed does not happen... > this file is never used again - it just hangs around in the > locked files > is left on the disk until the program is closed. > > I know this looks like a word bug... but the client computers have not > changed and I've only observed this phenomena since upgrading to > alpha22. > > How can i help debug this? > > brad > -- > Bradley W. Langhorst <[EMAIL PROTECTED]> >
Re: Users able to execute windows .exe though execute bit not set
On April 1, [EMAIL PROTECTED] said: > I'm looking for some assistance regarding file permissions and the inability > to stop the execution of a file even though the execute permission has not > been set. Execute bits are a Unix concept. Windows will execute any file it can read that it understands the extension of and has a handler for. Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. "After explaining the situation to the machine clearly with appropriate use of a screwdriver..." - Alan Cox
RE: Users able to execute windows .exe though execute bit not set
> -Original Message- > From: Nick Drouet [mailto:[EMAIL PROTECTED] > I'm looking for some assistance regarding file permissions > and the inability > to stop the execution of a file even though the execute > permission has not > been set. UNIX execute permission has no effect on the ability of Windows clients to execute a program. If they can read it, they can execute it. This makes sense if you think about it -- even if you could stop them from executing it on the server, they could still just copy it to a local drive and execute it if they had read permissions.
Users able to execute windows .exe though execute bit not set
I'm looking for some assistance regarding file permissions and the inability to stop the execution of a file even though the execute permission has not been set. Scenario I create a share. I copy the notepad.exe from a windows client onto the share. >From Linux console: chown notepad.exe chmod 600 notepad.exe >From Windows client: I map a drive to the share and I am still able to run the notepad.exe file from the share, even though executable permissions aren't set... I can remove the executable flag via the Windows GUI and the same occurs. I've tried other executable files and the same occurs. If I chmod 222 to remove any read rights, then I get the access denied that I would expect. As far as user permissions are going, I've tried a number of options. Originally I had a samba server as a member of a Windows NT Domain, using Winbind to map user IDs. This also had ACL support with the 2.4.17acl kernel and permissions were being set fine on multiple users from the NT domain. I've stripped elements out until I now have just a samba server which is not part of a domain and my windows user is in the smbpasswd file with matching user Id and password. At all stages this problem occurs. I need to know if I'm doing something very dumb here but the ability to stop users running executables from a network share is critical. Clients are Windows 2000 / NT4 Samba versions that I've tried are 2.2.8 and 2.0.0.15 (RPM from SuSE installation CD). Linux distros that I've tried are SuSE 7.2 and Redhat 7.2 Does anyone have any light they could throw onto why this is happening? I've seen a few threads regarding this in the samba general but no replies so forgive if off topic slightly but could really do with some hints.. Relevant bits from my smb.conf are below. [global] workgroup = DOMAIN2 guest account = nobody keep alive = 30 os level = 2 kernel oplocks = false security = domain encrypt passwords = yes socket options = TCP_NODELAY map to guest = Bad User wins server = 192.168.1.80 netbios name = samba1 winbind uid = 1000-2000 winbind gid = 1000-2000 winbind cache time = 10 winbind separator = + password server = * log file = /var/log/samba log level = 1 [share3] path = /share3 comment = shared area read only = no browseable = yes
Problem with samba 3.0 alpha 23
Hi, I'm trying to build alpha 23 on a debian machine here for a worker. Everything compiles great, and Active Directory option is enabled. However, after installing the build, trying to do: net ads join - gives me the message that net is not build with ADS support... I checked the config.log and the configure output - the Active Directory option is enabled.. I checked that I don't have previous version of samba (removed them all before build).. Any suggestions? (the worker is using debian sid). Thanks, Hetz
Re: HEAD fails to build with dmalloc enabled
On April 2, [EMAIL PROTECTED] said: > On Tue, 2003-04-01 at 23:41, Ronan Waide wrote: > > Compiling lib/adt_tree.c > > lib/adt_tree.c: In function `sorted_tree_destroy': > > lib/adt_tree.c:114: structure has no member named `_free_leap' > > make: *** [lib/adt_tree.o] Error 1 > > It's due to dmalloc() using a CPP define to do the work. Adding some > brackets often fixes the issue. Ok. having done make -k I've found a bunch more problems with dmalloc; I'll see what I can do about them. Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. "Even buddy can be hard after a few beers. You start wondering if there's two "d's" or one and if it's "ie" or "y". That's why we came up with: Dude! Although sometimes we end up calling each other "dud"." - Chuck O'Bryan
Re: HEAD fails to build with dmalloc enabled
On Tue, 2003-04-01 at 23:41, Ronan Waide wrote: > Compiling lib/adt_tree.c > lib/adt_tree.c: In function `sorted_tree_destroy': > lib/adt_tree.c:114: structure has no member named `_free_leap' > make: *** [lib/adt_tree.o] Error 1 It's due to dmalloc() using a CPP define to do the work. Adding some brackets often fixes the issue. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
FW: encrypt passwords=no, security=yes, samba 2.2.8, W2K user auth fails
Hi Tony, Another workaround would be to populate an smbpasswd file with all the names from your /etc/passwd file. But I realize this can be onerous. Samba has a script to help with this, mksmbpasswd.sh since you won't be needing passwords from this smbpasswd file, this would do it for you, I think if your distribution doesn't install this script, it can be found in the source at /usr/local/samba/source/script/mksmbpasswd.sh useage: cat /etc/passwd|./mksmbpasswd.sh >/usr/local/samba/var/private/smbpasswd Hope this helps Don
2_2 CVS Fails to Compile - rpc_server/srv_spoolss_nt.c
Compiling rpc_server/srv_spoolss_nt.c
rpc_server/srv_spoolss_nt.c: In function `open_printer_hnd':
rpc_server/srv_spoolss_nt.c:512: structure has no member named `ctx'
make: *** [rpc_server/srv_spoolss_nt.o] Error 1
Looks like something from 3_0 crept in... that version does define a member "ctx"
within the Printer
structure... this one does not. Maybe that inserted code needs to go (or more
infrastructure needs
to be added)?
Thanks, Rich B
Possible fix:
--- ../source/rpc_server/srv_spoolss_nt.c Tue Apr 1 07:15:19 2003
+++ ./rpc_server/srv_spoolss_nt.c Tue Apr 1 08:51:44 2003
@@ -509,12 +509,6 @@
new_printer->notify.option=NULL;
- if ( !(new_printer->ctx = talloc_init_named("Printer Entry [0x%x]", (uint32)hnd)) ) {
- DEBUG(0,("open_printer_hnd: talloc_init() failed!\n"));
- close_printer_handle(p, hnd);
- return False;
- }
-
if (!set_printer_hnd_printertype(new_printer, name)) {
close_printer_handle(p, hnd);
return False;
change share command
Greetings, add share command,delete share command and change share command are three parameters of smb.conf which I am trying to use.Samba sources has example script modify_samba_config.pl which can be used for addition and deletion of share .but which script can be used for change share command ? modify_samba_config.pl doesnot work for changing the share attributes.If anyone has this script please let me know. Awaiting for reply. -DJ __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://platinum.yahoo.com
Re: How to configure the file smb.conf
Hi Oliver,
please send this question to [EMAIL PROTECTED]
samba-technical is for developer dicussion only.
metze
At 14:32 01.04.2003 +0200, Olivier Studer wrote:
Hello,
I would like to mount a home directory UNIX on my PC. I use a server for
samba. And I try to have an authentification with a server ldap (IPlanet
product). But I can recive an authentification.
Could you help me, please.
Thanks
/Olivier
my smb.conf file:
=
[global]
log file = /usr/local/samba/log.%m
security = user
encrypt passwords = yes
workgroup =
# ldap related parameters
# define the DN to use when binding to the directory servers
# The password for this DN is not stored in smb.conf. Rather it
# must be set by using 'smbpasswd -w secretpw' to store the
# passphrase in the secrets.tdb file. If the "ldap admin dn" values
# changes, this password will need to be reset.
ldap admin dn = "cn=Directory Manager"
# specify the LDAP server's hostname (defaults to locahost)
ldap server = my-server-ldap.x.ch
# Define the SSL option when connecting to the directory
# ('off', 'start tls', or 'on' (default))
ldap ssl = off
# define the port to use in the LDAP session (defaults to 636 when
# "ldap ssl = on")
ldap port = 389
# specify the base DN to use when searching the directory
#ldap suffix = NOT USE
# generally the default ldap search filter is ok
ldap filter = "(&(uid=%u))"
[homes]
writable = yes
force directory mode = 755
browseable = no
create mode = 0750
force create mode = 755
comment = Home Directoriec
users = %S
only user = yes
[printers]
comment = All Printers
browseable = no
printable = yes
public = no
writable = no
create mode = 0700
metze
-
Stefan "metze" Metzmacher <[EMAIL PROTECTED]>
HEAD fails to build with dmalloc enabled
Compiling lib/adt_tree.c lib/adt_tree.c: In function `sorted_tree_destroy': lib/adt_tree.c:114: structure has no member named `_free_leap' make: *** [lib/adt_tree.o] Error 1 Cheers, Waider. -- [EMAIL PROTECTED] / Yes, it /is/ very personal of me. "Junk food is considered part of the vegetable food group, because it comes from a plant. A big chemical plant. In New Jersey." - Kludge Dorsey
Re: Problems with ACLs in 2.2.8
Hello Buck, Buck Huppmann wrote: i'm also seeing some aberrant ACL-setting behavior in samba 2.2.8. more- over, the new Creator Owner and Creator Group semantics are bewildering, although i can understand if, in that sense, they're just mimicking NT behavior all the more closely. at any rate, below's a patch that purports to do the following: 1. the hunk for util_sid.c make the Creator Owner and Creator Group icons show up appropriately in my NT-permissions-chooser thingy 2. the first three hunks for posix_acls.c allows one to drop entries from an ACL without having samba re-insert the ``missing'' ACEs behind the scenes with the share-default perms. this may or may not address your concern From my understanding Samba has no other choice than inserting missing object ACEs, because it's impossible to set a POSIX ACL without. The crucial point not being whether, but what to insert. What does the client intend when sending an ACL without object entries? The purpose of the modification in the new ACL code was to cope with W2k clients attempting to copy ACL from one file to another, as office apps are doing when storing into temporary files. Without preserving existing object ACEs the user who has just stored ends up without write permissions, if write access to the original file was only via a supplementary group. 3. the fourth hunk excepts Creator Owner and Creator Group from being dropped from the incoming ACL as ``non-mappable SIDs'' I'm not sure what it actually implies, but sounds promising. Hoping that this modication could get our missing ACEs "preserved" (i.e. assuming they do get transmitted but were filtered out) I tried your modifications from 2. and 3. Bad luck. Still breaks W2k clients copying ACLs to temp files. How do we want to cope with it? Cheers! Michael 4. the fifth hunk corrects for the fact that--according to the ``-s'' option description from the setfacl(1) man page of Solaris 2.6, anyway-- Solaris needs a default ``CLASS_OBJ'' entry if it has any other default ACL entries 5. the sixth hunk makes use of the mask_perms mode that set_canon_ace_list() munges all the way through but then does nothing with. this isn't required for correct functionality, though, i don't think 6. the seventh hunk (in NT4-compatible mode) abridges the code to elide the non-default ACL entry for the group owner if the group owner has no permissions, since i thought this might allay confusion, as indicated by the CPP macro name used there. again, this isn't required for correct functionality none of these are meant to be applied to anybody's samba source tree; i'm just trying to point out some areas that may need attention i think, however, for my purposes, i'm just going to drop in the old 2.2.7 posix_acls.c, since i find named ACEs with non-bogus perms in both parenthe- sized slots in the NT-permissions-thingy display much less confusing, if a bit misleading --buck On Tue, Mar 25, 2003 at 01:39:22AM +, Jan Houstek wrote: Hi all! I posted this in [EMAIL PROTECTED] but there were no reactions. Particulary I'm interested if anyone observe the same behavior. -- Honza Houstek -- server: linux 2.4.19 with xfs 1.2 and its ACL libacl 2.0.19 samba 2.2.8 compiled from source with --with-acl-support acting as PDC interesting parts of smb.conf create mask = 0600 directory mask = 0700 [testshare] path = /data/testshare readonly = No client: 1) Windows XP, servicepack 1.2a 2) smbmount from another linux box server:~# getfacl /data/testshare/testdir # file: testdir # owner: testuser # group: users user::rwx group::--- group:somegroup:r-x group:anothergroup:rwx mask::rwx other::--- default:user::rwx default:group::--- default:group:somegroup:r-x default:group:anothergroup:rwx default:mask::rwx default:other::--- server:~# umask 007 server:~# mkdir /data/testshare/testdir/test1 server:~# getfacl /data/testshare/testdir/test1 # file: test1 # owner: root # group: root user::rwx group::--- group:somegroup:r-x group:anothergroup:rwx mask::rwx other::--- default:user::rwx default:group::--- default:group:somegroup:r-x default:group:anothergroup:rwx default:mask::rwx default:other::--- On windows: logon to domain as testuser create test2 in testdir (right mouse button -> New -> Folder) server:~# getfacl /data/testshare/testdir/test2 # file: test2 # owner: testuser # group: users user::rwx group::rwx # !!! problem !!! group:somegroup:r-x group:anothergroup:rwx mask::rwx other::--- default:user::rwx default:group::--- default:group:somegroup:r-x default:group:anothergroup:rwx default:mask::rwx default:other::--- --- samba-2.2.8/source/lib/util_sid.c.orig Fri Mar 14 16:34:47 2003 +++ samba-2.2.8/source/lib/util_sid.c Mon Mar 31 07:5
How to configure the file smb.conf
Hello,
I would like to mount a home directory UNIX on my PC. I use a server for samba. And I
try to have an authentification with a server ldap (IPlanet product). But I can recive
an authentification.
Could you help me, please.
Thanks
/Olivier
my smb.conf file:
=
[global]
log file = /usr/local/samba/log.%m
security = user
encrypt passwords = yes
workgroup =
# ldap related parameters
# define the DN to use when binding to the directory servers
# The password for this DN is not stored in smb.conf. Rather it
# must be set by using 'smbpasswd -w secretpw' to store the
# passphrase in the secrets.tdb file. If the "ldap admin dn" values
# changes, this password will need to be reset.
ldap admin dn = "cn=Directory Manager"
# specify the LDAP server's hostname (defaults to locahost)
ldap server = my-server-ldap.x.ch
# Define the SSL option when connecting to the directory
# ('off', 'start tls', or 'on' (default))
ldap ssl = off
# define the port to use in the LDAP session (defaults to 636 when
# "ldap ssl = on")
ldap port = 389
# specify the base DN to use when searching the directory
#ldap suffix = NOT USE
# generally the default ldap search filter is ok
ldap filter = "(&(uid=%u))"
[homes]
writable = yes
force directory mode = 755
browseable = no
create mode = 0750
force create mode = 755
comment = Home Directoriec
users = %S
only user = yes
[printers]
comment = All Printers
browseable = no
printable = yes
public = no
writable = no
create mode = 0700
答复: ???`: ??????: When the keep-alive packet sent out,rfc1002 says different things!!
-原始邮件- 发件人: Christopher R. Hertel [mailto:[EMAIL PROTECTED] 发送时间: 2003年4月1日 15:29 收件人: Aladdin Cai(絆價_豎奻漆ㄘ 抄送: [EMAIL PROTECTED]; [EMAIL PROTECTED] 主题: Re: ???`: ??: When the keep-alive packet sent out,rfc1002 says different things!! On Tue, Apr 01, 2003 at 01:33:14PM +0800, [EMAIL PROTECTED] wrote: : > ...but they will be in sequence, not mixed. The WriteRaw OK message will > be a complete SMB message, so you will not have any trouble parsing them. > Just read the number of bytes specified in the NBT header's length field. > > ~~~ Here I'd ask a quite stupid question:) :If server sends > client two packets, one by one. > Until both are in socket buffer,client calls recv( ) to get > the all in buffer, will client get a mixture > or only the first packet? That's a very good question, actually... TCP provides a stream. The packets will be made available in the order in which they were sent, but *not* as discreet packets. You might call recv() and get the end of the last packet, all of the current packet, and the first part of the next packet. You have to collect and parse the input. The nature of the SMB protocol hides that fact. In general, the client will only get a message from the server if the client asked for it. You send a request, wait for the entire reply, then send another request. The keep-alive is one situation in which the messages can get interleaved. It can also happen if there are multiple processes using the same SMB connection. > If it is the first situation,Then,I have to suppose that it > is possible > that keep-alive is in front of WriteRaw OK,then I have to > remove first 4Bytes and get > WriteRaw OK.It is more troublesome. Could be ahead, could be behind. Fortunately, the NBT Session Service headers all provide a message length field. Yes, you do have to watch for and handle this situation. : > ~~ I 'd like to show you the read raw packet format, which I >have got using NAI sniffer4.6. Ethereal is recommended, if only because the rest of us know how to read it... ^^ Thanks, I will download it and try.Is it more powerful than NAI sniffer?NAI sniffer will treat a packet simply beginning with 0x85 as keep-alive, an obvious bug:) >I have make a picture,pls >see the attached file. You can see that in read raw,the first >packet has a netbios header,yet the others haven't. Okay. I wasn't sure about that. Thanks for letting me know. > As I have seen in rfc1002, server or client should reset > timer when they receive a packet. When they receive an *NBT* packet. The NBT keepalive timer is managed at the NBT layer. The TCP stream won't reset the timer, but the initial READ RAW request *should* reset the timer. But I think raw data is also an NBT packet,which is passed through to user layer. So, server is responsible to reset the timer anyway. And the read raw request , doesn't reset timer either, as I have seen,just between two read request, keep-alive occurs. > If so, we won't have to worry about keep-alive packet. > I don't know why they ignore this rule, introducing > so much complexity. What I can't tell from the graphic you sent is whether the keep-alive message is interleaved with the raw read messages. It shouldn't be because, as I've said, the initial READ RAW request from the client should reset the timer and the READ RAW itself should be finished before the timer expires. I really can't imagine Samba making the mistake of sending the keep-alive while it is in the middle of a READ RAW operation, but I would believe it if I saw a capture that shows it (an Ethereal capture would be best...www.ethereal.com...it's free). ^^^ I really don't see this too. What I have seen is that keep-alive appends to the head of response or a seperate keep-alive packet. But I have no evidence that it will NOT be sent out during raw data stream,especially in a mutithread environment. ^^^ And I find a way,in windows, there is a registry key controlling sessionkeepalive(it just name of it) So, I can switch it off then none of keep-alive can be sent out any more.If no other safer solution, I will do it this way. Windows... well, I suppose it would be easier to imagine, but I'd still want to see the capture. Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
