Bug 121744 - other computers can still access share after it has been unshared
other computers can still access share after it has been unshared
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: redhat-config-samba (Show other bugs)
1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Brent Fox
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-27 03:18 EDT by moonwalker
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-24 16:48:15 EDT
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 moonwalker 2004-04-27 03:18:22 EDT
Description of problem:


Version-Release number of selected component (if applicable):
Samba Server Configuration Tool 1.1.4

How reproducible:


Steps to Reproduce:
1.create a share
2.access it from another machine
3.remove share

  
Actual results:
access attempts still successful. can still open subdirectories and
copy files from the share

this was tested in readonly mode

Expected results:
share should cease to be accessable


Additional info:


server
fedora core 1, clean install, all updates from channel fedora-core-1
from  http://download.fedora.redhat.com/pub/fedora/linux/core/1/i386/os/
as of 04.27.2004

client 
win xp pro sp1
Comment 1 Mark J. Cox (Product Security) 2004-05-06 05:46:56 EDT
Can you give details on what you did in step 3 "remove share"; did you
restart samba?
Comment 2 moonwalker 2004-05-06 07:35:19 EDT
did not restart samba. simply removed share via redhat-config-samba. 
this apears to reside with the tool itself because ive since moved to 
swat and the shares stop access as soon as i disable or remove them 
via swat. also i noticed redhat-config-samba making changes to the 
smb.conf file while in security setting that were unralated to the 
settings i was changing. i had to go back with swat and remedy the 
changes

such as guest being constantly mapped to "nobody" even though i set 
it to no guest account last time.

try it on a fresh fc1 machine with all updates youl find its VERY 
repeatable
Comment 3 moonwalker 2004-05-06 07:39:00 EDT
actually i take that back - i also tryed restarting samba after the 
changes to no avail - i did not monitor the changes to smb.conf so i 
didnt notice whether or not it was successfully removed from the file 
or not
Comment 4 Brent Fox 2004-05-06 16:07:52 EDT
Mark: redhat-config-samba will restart the smb daemon every time a
change is made, so it shouldn't be necessary for the user to manually
restart the service.

moonwalker: It would be helpful if you could attach an smb.conf file
before and after using redhat-config-samba so I can try to determine
exactly what is being changed in the file.  Also provide the exact
steps that you took to make the changes with the user interface.
Comment 5 moonwalker 2004-05-07 01:05:48 EDT
unfortunately this is a production server slated to go online in 7 
days. ive just learned to stay away from redhat-config-samba for now. 
if i get some time and get it ready for active duty ahead of schedule 
then ill go back and reproduce the error in detail.

the thing i noticed it changing is guest access parms mostly.
Comment 6 Brent Fox 2004-06-24 16:48:15 EDT
The bug with the guest account getting reset to "nobody" is a dupe of
bug #121745 and is fixed in system-config-samba-1.2.11-1.

I am not able to reproduce the problem with the share still being
accessible after it's been deleted from system-config-samba.  I'm
running system-config-samba-1.2.12-1 on an FC2 box and the client is a
RHEL3 AS system.  I don't have a Windows box handy to try that.  

Since I'm not able to reproduce this problem, I'm going to close as
'worksforme'.  Please reopen if you see the behavior on an FC2 machine.

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