loadparm in Samba4

[simo]

On Sat, 2006-09-16 at 12:31 -0500, tridge at samba.org wrote:
> Simo,
> 
>  > Given your strong opinion it seem a lost battle for me, but I know it is
>  > not so easy to understand what's going on when you change the share ACL
>  > form a windows box and still you can't access the files or even a share.
>  > That's because form a win box you don't see the read only, valid users,
>  > etcc.. parms (at least that's what happen in samba3).
> 
> hmm, I guess we're coming at this from different perspectives. You're
> thinking of making life easier for people who primarily configure via
> windows management interfaces. I'm trying to keep it sane for people
> who don't :)

Yes the whole idea behind share_ldb is to make life easy for management
applications, so that you can easily build configuration tools or use
the MSRPC API.

>  > That's why I am not proposing to get rid of these parameters, but use
>  > them to build up a virtual ACL. I want to get rid of of lp_readonly()
>  > not of the read only parameter in share_classic.
> 
> ok, if you're not proposing to actually remove these parameters then I
> can lower my spines a little :-)
> 
> How would you handle the case where an admin edits smb.conf, marks a
> share read-only but doesn't update the ACL on the share? I'd want that
> to cause a share to become read only.

Well my idea was to convert the smb.conf parameters into an ACL
internally.

So if we have a share configured this way:

read only = yes
valid users = +DOMAIN\Domain Users
write list = +DOMAIN\Domain Admins
invalid users = joe

This internally would be translated to  an ACL like:
DENY ALL joe
ALLOW RW DOMAIN\Domain Admins
ALLOW RO DOMAIN\Domain Users
DENY Everyone

We generate this ACL only when we connect to the share and keep it
around.
If the admins changes the smb.conf file the ACL will be changed
accordingly.

Basically my idea is that if you use share_classic you will not be able
to set arbitrary ACLs, but everything you do must be translated back
into a set of read only/(in)valid users/read(write) list sets to be
written back to smb.conf (if that's allowed, otherwise the ACL will
simply be not manageable from the srvsvc pipe).

On the other hand if you use share_ldb you will not be able to set any
of these parameters but each share will only obey to the ACL we will
store on a security descriptor attribute.
I think that if an admin wants to use share_ldb, then he will use admin
tools to manage it anyway and we can easily build a little smbscript
tool to manage share an ACLs via the srvsvc pipe so that shares will be
manageable from the CLI. It make sense even for share_classic if we will
implement a way to write changes back which should not be too hard with
a scripting language (not sure ejs is feature rich enough, but it is
easier than C probably anyway).

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org