On 09/22/09 11:46, Afshin Salek wrote:
I have been considering whether or not it makes sense to apply a
read-only ACL to smbautohome shares with a single ACE that grants
the owner Full Control. Given that we already filter based on the
owner, perhaps we shouldn't allow anyone else to have access to the
share.
I think it would make more sense if this restriction is applied to
the home directory when it is created rather than the autohome share
ACL, because I think the owner wouldn't want anybody locally or over
NFS has access to his/her data either.
That's more of a discretionary thing, I was thinking more of a
policy related to smbautohome shares.
The directory ACL may allow some access to members of the owner's
primary group, a parent directory may be shared or there may be
a persistent share with a different ACL.
Alan
Afshin
Alan
----- Original Message ----- Alan M Wright <a...@sun.com> wrote:
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
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
