On 09/21/09 01:13, Jim Klimov wrote:
Also, if the share name and ACL pseudofile name are the same, how well is it
supported to rename shares (while keeping the old ACL)? What should the
proper procedure be? I don't think I can create or copy a file in .zfs/shares,
The system takes care of share rename. If you rename a share,
the name in .zfs/shares will change and the ACL will remain
consistent on the share.
And now that I'm aware of this, I wonder what are the security implications
(and insecurity windows) of these generic sharing steps:
1) Create a dataset
2) (optional - should become a must) Protect the dataset with directory ACLs
3) run "zfs set sharesmb=... data/set ", or have the autoshare via smbautohome
4) (for some time there is a CIFS share allowing anything by default)
5) Edit the ACL on the .zfs/shares/name file to fine-tune the access rights
The window (4) concerns me now that I thought of it. Especially if there is no
regular practice of pre-setting FS ACLs (2). In this case it can be as long as
months, until somebody cares to check. And now I think smbautohomes' filters
for username access only are indeed a good thing, with the FS defaults being
like "chmod 755"...
Given that the default is consistent with Windows, leaving a share
(that should be protected) wide-open for several months would seem
to be an administration error, and the window of opportunity to
access a new share should be no worse than with Windows when using
Computer Management to manage shares.
If security really is a concern, you can disable the CIFS service
while creating shares and setting share ACLs, which could be scripted
and run during off-peak hours.
If you can't take the downtime, use Computer Management to watch for
connections while creating/protecting shares. If you see someone
who shouldn't have access connect to the share, disconnect them.
Assuming we were to do as you suggest,
.zfs/shares would contain an entry for every smbautohome
share that had ever been created and they would never go away.
That could be worked around with a manual "unshare" call, perhaps (maybe better
than letting admins remove the ACL pseudofile entry)?
I'm not keen on any manual component to smbautohome.
And, isn't there only one such entry in a user's home dataset?
Or does the system also provide for a single common /export/home dataset with
multiple home dirs (not datasets) inside?
Yes, a single dataset can support many home directories.
Alan
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
