Bug 7549 - No error given when accessing share belongs to other user after successful authentication
Summary: No error given when accessing share belongs to other user after successful au...
Status: RESOLVED INVALID
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.13.2
Hardware: x64 Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-05 03:42 UTC by erha (dead mail address)
Modified: 2020-12-22 08:53 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description erha (dead mail address) 2010-07-05 03:42:35 UTC
Problem:
No error given when accessing share belongs to other user after authentication.
Even though the content shown is belong to yourself (the authenticated user) but this give impression to the end-user (the non-IT-user of course) that they can actually access other people files.

Server OS: CentOS 5.4
Client OS: Win7 and WinXP
Samba: 3.5.3 and 3.5.4 (tried on 3.5.3 and upgrade to 3.5.4, problem persist)
Platform: x64
Reproducable: ALWAYS

Configuration file:
[global]
  workgroup = myWorkgroup
  security = user
  passdb backend = tdbsam
  passwd program =  /usr/bin/passwd %u
  passwd chat=*New\sPassword:\s%n\nRe-enter\snew\sPassword:\s%n\npasswd:\spassword\ssuccessfully\schanged*\n

  unix password sync = Yes
  passwd chat debug = yes
  passwd chat timeout = 10

  log level = 10
  max log size = 50
  debug timestamp = yes

[homes]
  browseable = no
  writable = yes
  valid users = %U
  force user = %U
  path = %H

Step to reproduce:
1. On the server, create 2 different users (i.e. user1 and user2) and create a password for the samba using smbpasswd
2. On the client, type in "\\ipaddress" from Windows Start->Run, type in user id and password for user1.
3. The explore will show you a folder user1 (Note: only user1).
4. On the client, type in "\\ipaddress\user2" from Windows Start->Run

Result:
The explorer will show \\ipaddress\user2 in the address bar but the content shown comes from \\ipaddress\user1.

Expected:
When we enter \\ipaddress\user2, the explorer shall give an error as user2 folder shall not be accessible by user1.

5. After this when I try to access by typing \\ipaddress from Start->Run, I could see 2 folders user1 and user2.

6. From now on, you always see 2 folders (user1 and user2).

I have sniffed the traffic and check the NetShareEnumAll response and unfortunately the server did return user1 and user2, so this is not a problem on WinXP or Win7.
Comment 1 Björn Jacke 2020-11-16 10:44:52 UTC
this is still the same with current 4.13 - if you open a foreign user's home share, then this is being enumerated for the user who opened it from that point on.

Shouldn't the rigt aproach for out special homes share be to only enumerate the authenticated user's home share and not enumerate "accidentally" access foreign home shares?
Comment 2 Björn Jacke 2020-11-16 10:51:34 UTC
by the way: the effect that you reported, that *you* home directory is listed when you access a foreign user's homedir, comes probably from the (bad) combination of "force user", "path" and "valid users" parameters. You might want to try to use "valid users = %S".

Still the point that I see is the share enumeration after an attempted access.
Comment 3 Rowland Penny 2020-12-21 12:17:58 UTC
I agree with Bjorn, this was caused by misconfiguration of the 'homes' share. Standard on Debian it is this:

[homes]
   comment = Home Directories
   browseable = no
   read only = yes
   create mask = 0700
   directory mask = 0700
   valid users = %S

There are also these comments:

# By default, \\server\username shares can be connected to by anyone
# with access to the samba server.
# The following parameter makes sure that only "username" can connect
# to \\server\username

So, by my reading and experience, if the 'homes' share is set up as above, there isn't a problem.

If you agree Bjorn, I think we can close this bug report.
Comment 4 Rowland Penny 2020-12-22 08:53:02 UTC
Closing, not a bug, invalid configuration.