samba - Nov 1999 - 2.0.6: HUP/charset/profiles/smbmount/logging

This is the list of problems I had with samba-2.0.6 so far. Can anyone
tell me if he can reproduce them and if he considers them as problems?

2.0.6 on linux 2.2.13 or 2.0.33

1)
sighup/log reopening doesn't always work: connections that are already
active keep logging to the old logs; logrotate rotates/zip the logs and
samba stops logging completely till restart.

2)
Localized chars.
I have
character set = iso8859-1
client code page = 850
>From windows explorer to samba all is ok.
>From samba (smbclient/smbmount) the localized chars on windows shared
dirs are unreadable.

3)
The change to make "net use h: /home" works, makes the logon path
directive not effective (profiles go into the home-share whatever you
put in "logon path").
This issue has already been discussed a lot on the list.

4)
smbmount # 1
If:
- someone has and HD (Win9x) where the volume label of the HD is "xyz"
- there is a dir "c:\xyz", 
- the c:\ rootdir is shared (say as "c")
Then when the HD is smbmounted the c:\xyz dir will appear as a file
(really as a "VOLUME ARCHIVE") and not a dir, its content won't be
available.
To solve this either change the volume label or the dir name.
Smbclient in not affected.
This is real-time, if you change the volume label while the disk is
smbmounted you see the dir re-becoming a dir and vice-versa.

5) (security)
smbmount # 2
When a password protected win9x share is mounted, the username and the
length of the password used to mount it are in the ps output.

6) (security)
samba doesn't log (at standard log level)  the ip address of a machine
which tries to connect with a wrong password, or that tries to access a
share as an user not in "valid users". I'd like to know who is
trying to
access a non-public share using every possible password.

7)
I have 2.0.6-PDC and a 2.0.6-domain-member of the 1st pdc.
Authentication works ok, the domain member has an empty smbpasswd file.
When I connect to my homeshare on the domain member I get

[1999/11/16 17:25:06, 1] smbd/password.c:pass_check_smb(505)
  Couldn't find user 'go' in smb_passwd file.
[1999/11/16 17:25:06, 1] smbd/service.c:make_connection(535)
  go (10.0.0.173) connect to service go as user go (uid=105, gid=100)
(pid 21278)

I don't understand why it logs that it can't find "go" in
smbpasswd
since the primary auth source is the pdc which gives ok to my
userid/password pair. It shouldn't look at the smbpasswd file at all if
the pdc is there, should it?
I mean: all is ok, but the log says something that could be interpreted
as a problem. I routinely grep the logs for anomalies and these are
false positives.


============= sighup/log
this file, log.smb.1, was renamed from log.smb to log.smb.1 before the
HUP, as you can see samba keeps logging to it after the HUP.

[1999/11/16 16:58:38, 1] smbd/server.c:main(643)
  smbd version 2.0.6 started.
  Copyright Andrew Tridgell 1992-1998
[1999/11/16 16:58:38, 1] smbd/files.c:file_init(216)
  file_init: Information only: requested 10000 open files, 246 are
available.
[1999/11/16 16:58:47, 1] smbd/password.c:pass_check_smb(505)
  Couldn't find user 'go' in smb_passwd file.
[1999/11/16 16:58:49, 1] smbd/password.c:pass_check_smb(505)
  Couldn't find user 'go' in smb_passwd file.
[1999/11/16 16:58:49, 1] smbd/service.c:make_connection(535)
  go (100.0.173) connect to service windows as user cdi (uid=100,
gid=100) (pid 21166)
[1999/11/16 16:59:01, 0] smbd/server.c:sig_hup(342)
  Got SIGHUP
[1999/11/16 16:59:01, 0] smbd/server.c:sig_hup(342)
  Got SIGHUP
[1999/11/16 16:59:09, 1] smbd/password.c:pass_check_smb(505)
  Couldn't find user 'go' in smb_passwd file.
[1999/11/16 16:59:09, 1] smbd/service.c:make_connection(535)
  go (10.0.0.173) connect to service go as user go (uid=105, gid=100)
(pid 21166)
[1999/11/16 16:59:10, 1] smbd/password.c:pass_check_smb(505)
  Couldn't find user 'go' in smb_passwd file.
[1999/11/16 16:59:10, 1] smbd/password.c:pass_check_smb(505)
  Couldn't find user 'cdi' in smb_passwd file.
[1999/11/16 16:59:11, 1] smbd/password.c:pass_check_smb(505)
  Couldn't find user 'go' in smb_passwd file.
[1999/11/16 16:59:11, 1] smbd/service.c:make_connection(535)
  go (10.0.0.173) connect to service giulio as user go (uid=105,
gid=100) (pid21166)


-- 
giulioo@tiscalinet.it

On Wed, 17 Nov 1999, Giulio Orsero wrote:
> 2)
> Localized chars.
> I have
> character set = iso8859-1
> client code page = 850
> 
> >From windows explorer to samba all is ok.
> >From samba (smbclient/smbmount) the localized chars on windows shared
> dirs are unreadable.
Known and a problem (Tridge knows and is/was thinking about a clean
solution). But doesn't smbclient show the filenames correctly? I was sure
that it did.

I have one way of doing this in smbfs, it can be found at
http://www.hojdpunkten.ac.se/054/samba/

Look for the nls thing ... (it's a smbfs and an optional smbmount patch).
If it doesn't apply cleanly just let me know and I'll upgrade it (should
be trivial).
You need to tweak the header file to choose the translation, or patch
smbmount too (and then tweak the header to tell it so). You need to
reconfigure and recompile your kernel (module?) to enable this.


Artem V. Ryabov <artem@abak.ru>
http://linux-patches.rock-projects.com/v2.2-f/smbfs-nls.html

has a different and in some ways better (more efficient) way of doing the
same thing. Don't know if it is updated to the latest.

> 5) (security)
> smbmount # 2
> When a password protected win9x share is mounted, the username and the
> length of the password used to mount it are in the ps output.
  ^^^^^^
Yes. Personally I don't care enough to try and fix it. Look in
source/client/smbmount.c:parse_mount_smb, it should be obvious what to
change.

/Urban

Hi Giulioo,

I found another thing that's either a problem or a feature. As of SWAT
2.0.6, a user/group not able to write smb.conf cannot see its shares,
globals or printers because he doesn't have those three navigation buttons.
This bug or feature can be reverted by moving three statements in swat.c
function static show_main_buttons(). Moving these three statements:

image_link("Globals", "globals",
"images/globals.gif");
image_link("Shares", "shares",
"images/shares.gif");
image_link("Printers", "printers",
"images/printers.gif");

out of if (have_write_access) and into if (have_read_access) right below it
reverts the behavior back to the 2.0.5a behavior where read-only smb.conf
permissions give access to globals, shares and printers, but without delete
or commit changes buttons.

Like I say, I don't know if this change was a security beef-up or if
it's a
bug. I reproduced this with 2.0.6 stable, on almost stock (recompiled
kernel from RH6.0 source) Red Hat 6.

Thanks

Steve Litt





At 07:26 PM 11/17/1999 +1100, Giulio Orsero wrote:
>This is the list of problems I had with samba-2.0.6 so far. Can anyone
>tell me if he can reproduce them and if he considers them as problems?
>
>2.0.6 on linux 2.2.13 or 2.0.33
[clip]
giulioo@tiscalinet.it

On Wed, 17 Nov 1999 22:28:22 +0100 (CET), hai scritto:
>between these. Did you then also change the kernel include:
>include/linux/smb_mount.h
>  so that it defines:
>#define SMBMOUNT_PATCHED
No, I fotgot this.

I re-did all the stuff and now it works. I see and can create filenames
with accented characters ok.

I use
mount -t smbfs -o guest,localpage=iso8859-1,rmtpage=cp850 //GO/A
test1

Thanks.

-- 
giulioo@tiscalinet.it

--On den 18 november 1999, 08:30 +1100 Urban Widmark
<urban@svenskatest.se>
wrote:
> On Thu, 18 Nov 1999, Giulio Orsero wrote:
>> With smbclient I see weird chars in place of the right ones.
> 
> Yes you are right. The same thing in smbclient is
> r?d
> 
> Either I misremember (is there such a word? :) or this is something that
> have changed since previous samba versions (or is now misconfigured on
> my/our part).
> 
Something must have changed in 2.0.6 (we have 2.0.5a), because when I try
it, smbclient works just as it should with respect to iso-8895-1
characters. I tested on two machines, one with:

   character set = iso8859-1
   client code page = 850

And the other with client code page undefined.

I suppose we should be careful about upgrading, in case the problem also
affects some Microsoft clients. Thanks for the warning.

Otto Giesenfeld