Keeping clients out of some file systems

Ronald Kuetemeier ronald at
Tue May 15 00:09:24 GMT 2001

I have implemented file-system/dir blocking. The dir will only be
blocked if they are referenced from a share by a link.
For example:

[ blocked ]
mount_point = /proc
mount_point = /
mount_point = /usr
dir_name = /usr/local/src/samba
END conf file;

DIRs and links:
DIR a: /usr/local/src/linux
DIR b: /usr/local/src/samba
LINK on SHARE [home] c: [/home/ronald]local->/usr/local
LINK on SHARE [home] d: [/home/ronald]samba->/usr/local/samba

Then everything on file-system /proc,/, and /usr is not accessible via
a link from a share, also /usr/local/src/samba is not accessible from
a link on a share.
For example the dir /usr/local/src/linux (a) is accessible from link c, but
/usr/local/src/samba (b) is not accessible from link c. That (b) is blocked
from link d should be self explaining.
ALso if you share /usr/local/ all is up to normal permission checking.

Attached source, as usual 2.2.0 --with-vfs is needed.

> On Sat, May 12, 2001 at 10:26:19AM +0900, okuyamak at wrote:
>>Dear Michael,
>>>>>>>"MG" == Michael Gerdts <Michael.Gerdts at> writes:
>>MG> Typically to keep clients out of file systems that they should not be
>>MG> poking around on (/ /usr, /var, ...) you have to use "wide links = no",
>>MG> which apparently has performance problems.
>>MG> Generally, I don't care if people have symbolic links that point out of
>>MG> their shares, so long as they don't give away information that they can't
>>MG> already get through NFS.  That is, if Alice has a symbolic link to Bob's
>>MG> home directory, I don't care.  If Alice has a symbolic link to /, I care.
>>MG> Perhaps a new option, "hide filesystems" would be useful.
>>MG> 	hide file systems = / /opt /usr/local
>>Beside performance, we sometime needs to share some partial directories.
>>For example, we might need to hide /home except for /home/<that
>>user>, and /home/share.
>>Maybe we need 'jail' support too.
>>By the way, followings are the directories I think we should not
>>share with Samba, nor have example about it. Any opinion?
>>* Directories that subdirectories might need to share, but should
>>  not share itself:
>>/, /var, /home, 
>>* Directories that subdirectories also should not be shared:
>>/etc, /bin, /lib, /sbin, /usr/sbin, /usr/bin, /usr/lib, /usr/share,
>>/usr/local/bin, /usr/local/share, /usr/local/lib, /usr/local/sbin,
>> /var/* except for /var/spool in case of printing,
>>/usr/local/samba ( or any other place where samba and it's setting exists ),
>>/opt /usr/lpp and other 'OS dependent' directories for binaries.
>># rules so far:
>># 1) we should not share directories which can lead to anywhere.
>># 2) we should not share binaries ( which never runs on Windows )
>>#    nor libraries
>># 3) we should not share any setting files about the server.
>># 4) we should not share any log, etc. which gives cracker extra hint
>>#    about the server
>># 5) we should not, among all, share samba directories which we might
>>#    give tremendeus hints of cracking.
>>Kenichi Okuyama at Tokyo Research Lab. IBM-Japan, Co.
>> Part 1.1
>> Content-Type:
>> text/plain
>> ------------------------------------------------------------------------
>> vfs-block.tgz
>> Content-Type:
>> application/x-tar-gz
>> Content-Encoding:
>> base64

-------------- next part --------------
A non-text attachment was scrubbed...
Name: vfs-block.tgz
Type: application/octet-stream
Size: 3303 bytes
Desc: not available
Url :

More information about the samba-technical mailing list