Keeping clients out of some file systems
okuyamak at dd.iij4u.or.jp
okuyamak at dd.iij4u.or.jp
Sat May 12 01:26:19 GMT 2001
Dear Michael,
>>>>> "MG" == Michael Gerdts <Michael.Gerdts at usa.alcatel.com> 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,
/usr/X11*,
/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.
More information about the samba-technical
mailing list