Bug 139960 - Windows client can access unshared(!) server directory
Windows client can access unshared(!) server directory
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: samba (Show other bugs)
3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jay Fenlason
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-18 17:24 EST by Christian Ziemski
Modified: 2014-08-31 19:26 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-30 23:37:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christian Ziemski 2004-11-18 17:24:11 EST
Description of problem:
On the Windows2000 client I'm using Ontrack's PowerDesk 4.0.12.1 as 
file-manager (the problem seems to have to do with the client.)

After opening the context menu of a Samba share named "RPMS" suddenly 
the file-manager listed an additional share: "rpm" with the contents 
of the directory /var/lib/rpm !!!

Detailed infos below.

Hopefully I was able to describe it understandable and perhaps 
someone can replicate it.


Christian



Version-Release number of selected component (if applicable):
samba-3.0.8-0.pre1.3

How reproducible:
Always

Steps to Reproduce:
I did some tries with a Windows2000 client connected to Samba 
installed on a FC3 box.

Here my simple smb.conf:
------------------------------------------------------
    # Samba config file created using SWAT
    # from 127.0.0.1 (127.0.0.1)
    # Date: 2004/11/18 22:18:04

    # Global parameters
    [global]
            workgroup = EBG-LAN
            server string = Samba Server
            security = SHARE
            password server = None
            username map = /etc/samba/smbusers
            log file = /var/log/samba/%m.log
            max log size = 50
            socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
            printcap name = /etc/printcap
            dns proxy = No
            idmap uid = 16777216-33554431
            idmap gid = 16777216-33554431
            guest ok = Yes
            hosts allow = 192.168.1., 127.
            cups options = raw

    [homes]
            comment = Home Directories

    [printers]
            comment = All Printers
            path = /var/spool/samba
            printable = Yes
            browseable = No

    [dvd]
            path = /media/cdrom

    [share]
            comment = Data2share
            path = /home/share
            read only = No

    [RPMS]
            comment = FC3-RPMS
            path = /FC3/RPMS
------------------------------------------------------



(Since I have a German Windows installation I'm trying to translate
the following names to the hopefully correct English ones.)

On the Windows2000 client I'm using Ontrack's PowerDesk 4.0.12.1 as 
file-manager (the problem seems to have to do with the client.)

In it I navigated to 
  "Network Neighbourhood"
    "Whole Network"
      "Microsoft Windows Network"
        <my domain>
          <my Samba server>
         
         
The Samba shares are shown as expected here. 

Now I opened the context menu for one share after another to show 
the properties.

And here it happened: After opening the context menu of the share 
"RPMS" suddenly the file-manager listed an additional share: "rpm" 
with the contents of the directory /var/lib/rpm !!!

That only happens with that share.

Looking at /var/log/messages showed

  : [2004/11/18 21:53:01, 0] smbd/service.c:make_connection(800) 
  :   nt02 (192.168.1.1) couldn't find service dv 
  : [2004/11/18 21:53:01, 0] smbd/service.c:make_connection(800) 
  :   nt02 (192.168.1.1) couldn't find service dv 
  : [2004/11/18 21:53:27, 0] smbd/service.c:make_connection(800) 
  :   nt02 (192.168.1.1) couldn't find service home 
  : [2004/11/18 21:53:27, 0] smbd/service.c:make_connection(800) 
  :   nt02 (192.168.1.1) couldn't find service home 

But those "couldn't find service" messages with the 
by-one-character-crippled share names are only showing for the other 
shares. The share "RPMS" ("expected" to be "rpm") here isn't.

This effect/error doesn't happen with the original Windows Explorer,
so I think it's a bug in PowerDesk too. (But Explorer lists the
phantom share too, it just doesn't seem to be able to create it.)
Anyway: Samba shouldn't give access to unshared directories!

Another interesting behaviour: When I reconfigure Samba and give 
the path "/home" to the initially empty share "homes" then the 
in PowerDesk newly listed share "rpm" doesn't contain /var/lib/rpm 
any longer but the directories under /home...
Comment 1 Nalin Dahyabhai 2004-11-18 18:20:02 EST
The "rpm" share corresponds to the home directory of the "rpm" user,
which is shared because your smb.conf file includes a section with the
reserved name of "homes".

The "homes" section includes default settings for home directory
shares ("homes" is a reserved name for a share), and setting a path in
that share will doubtless cause weird things to happen to shared home
directories.
Comment 2 Christian Ziemski 2004-11-19 01:52:50 EST
But why isn't the "rpm" share visible initially, only after opening 
the context menu of "RPMS"?
And why is it showing only after creating a share "RPMS"?

I tested again: It does happen with other shares too which are named 
one character longer than an existing Linux user. (e.g. "ftp2", 
"root3").

There *is* happening something strange here!

You wrote: "[path in homes share cause weird things]"
That shouldn't happen! It's easy to have a not perfectly correct Samba 
configuration... It should be a bit more secure (defensive).

Even with a correct configuration Samba shares too much in those 
cases, IMHO.

I'll do more testing later today.
Comment 3 Matthew Miller 2006-07-10 17:09:38 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 4 John Thacker 2006-10-30 23:37:14 EST
Closing per lack of response to previous request for information.
This bug was originally filed against a much earlier version of Fedora
Core, and significant changes have taken place since the last version
for which this bug is confirmed.

Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

Note You need to log in before you can comment on or make changes to this bug.