loadparm in Samba4

[tridge at samba.org]

Simo,

 > I think we should get rid of any frequent calls to loadparm, and have
 > all the most needed and speed sensitive option cached on a per share
 > structure.

ok, that's fine, as long as we actually do this. It's been quite a
long time since this new loadparm code went in, and we still have
quite a few speed sensitive calls to lp_ routines.

 > About the readonly parm, I'd really like to get rid of it
 > completely or confine it into a generic ACL check. When you use Windows
 > mgmt tools to create or manipulate share there is no way to manipulate
 > it, so I'd really like to move to a model where we use only Share
 > ACLs.

You want to get rid of 'read only = yes'? no way!

The 'be like windows' argument just doesn't apply. We want to make
Samba _easier_ to configure, not harder, and the "read only = yes/no"
option is vastly easier to understand and configure than an ACL.

I would be delighted for us to also have an ACL, but you'll remove
'read only = yes' as a overriding option over my dead body ;-)

That said, you may notice btw that the PVFS_FLAG_READONLY flag is now
checked in the posix backend as part of the ACL checking. See the call
to pvfs_read_only() in pvfs_acl.c. That way it honors 'read only =
yes', but it does it by effectively masking whatever ACL it would have
used with all the acl access bits that involve writes.

 > This means that real share ACLs will not be available if the
 > share_classic backend is used, but in my experience this is only a good
 > thing, because mixing readonly/valid user etc... with share ACLs is
 > always a disaster in the end. Only a handful of careful admins would be
 > able to mix them and still understand whats going on.

I don't believe this at all! I think its perfectly obvious that 
"read only = yes" is an override for anything else set on the
share. Similarly I think that "valid users" is a perfectly obvious
override for the list of users who can do a tcon.

Overrides like these make admins lives much easier. There is no way we
should remove them.

Cheers, Tridge