[Samba] Reverse Veto Files - let's try again!
Illtud Daniel
take the opportunity to repost a message that got no
answers in March:
I've searched the list, and I can't find reference to this being
implemented:
reverse veto files - a list of files *allowed* rather than
the current list of files *denied*. Possibly implemented by
just allowing a ! in the veto files directive.
eg:
veto files = /!*.png/!*.gif/
= only allow pngs and gifs to be read or written through that
share.
(though that's probably not the best syntax)
I still think it's a good idea that I would find really
valuable.
Was this discussed further? Has it been implemented under
another directive that I've missed? Has my google-foo let
me down?
--
Illtud Daniel illtud...@llgc.org.uk
Prif Swyddog Technoleg Chief Technical Officer
Llyfrgell Genedlaethol Cymru National Library of Wales
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
Jeremy Allison
> Since the list responsiveness seems to be at a high, le me
> take the opportunity to repost a message that got no
> answers in March:
>
>
> I've searched the list, and I can't find reference to this being
> implemented:
>
> reverse veto files - a list of files *allowed* rather than
> the current list of files *denied*. Possibly implemented by
> just allowing a ! in the veto files directive.
>
> eg:
>
> veto files = /!*.png/!*.gif/
>
> = only allow pngs and gifs to be read or written through that
> share.
>
> (though that's probably not the best syntax)
>
> I still think it's a good idea that I would find really
> valuable.
It's doable, but I wouldn't use that syntax. I'd
use an "allowed files = /XXX/" style.
> Was this discussed further? Has it been implemented under
> another directive that I've missed? Has my google-foo let
> me down?
Not been implemented yet.... Patch welcome :-).
Jeremy.
Illtud Daniel
> It's doable, but I wouldn't use that syntax. I'd
> use an "allowed files = /XXX/" style.
That's what I was thinking, but the question started
off as 'does veto files take !', so that's where my
convoluted syntax example came from.
> Not been implemented yet.... Patch welcome :-).
I've barely touched C since before I started using samba
(and that's 15 years ago...) but if you insist, I'll
cludge something together in a week that'll take somebody
else five minutes to completely rewrite... :)
Any preference for precedence of 'allowed files' vs 'veto files'?
Or would you want an apache-style 'Order allowed veto' option?
(please say no).
--
Illtud Daniel illtud...@llgc.org.uk
Prif Swyddog Technoleg Chief Technical Officer
Llyfrgell Genedlaethol Cymru National Library of Wales
Jeremy Allison
> Jeremy Allison wrote:
>
>> It's doable, but I wouldn't use that syntax. I'd
>> use an "allowed files = /XXX/" style.
>
> That's what I was thinking, but the question started
> off as 'does veto files take !', so that's where my
> convoluted syntax example came from.
>
>> Not been implemented yet.... Patch welcome :-).
>
> I've barely touched C since before I started using samba
> (and that's 15 years ago...) but if you insist, I'll
> cludge something together in a week that'll take somebody
> else five minutes to completely rewrite... :)
Thanks -but at least you'll give me something to work on :-).
> Any preference for precedence of 'allowed files' vs 'veto files'?
> Or would you want an apache-style 'Order allowed veto' option?
> (please say no).
veto files should take precedence.
Jeremy.
Charles Marcus
>> Any preference for precedence of 'allowed files' vs 'veto files'?
>> Or would you want an apache-style 'Order allowed veto' option?
>> (please say no).
> veto files should take precedence.
The way postfix does this when blocking ip ranges but excepting certain
hosts, you specify the 'allowed' hosts first, then the ip range to be
blocked.
They also use the ! character to mean 'NOT', so, in that context, if you
wanted to only allow .jpg files, it would be:
veto files = !*.jpg !*.jpeg *.*
--
Best regards,
Charles
Illtud Daniel
> veto files should take precedence.
How would that work if you wanted to veto everything except
(as Charles suggested) jpeg files? If I did:
Veto Files= /*/
Allowed Files= /*.jpg/
If Veto takes precedence, this isn't going to do it, is it?
I think I'm answering my own question - without a not operator
in 'veto files', the allowed files must take precedence, mustn't
it?
--
Illtud Daniel illtud...@llgc.org.uk
Prif Swyddog Technoleg Chief Technical Officer
Llyfrgell Genedlaethol Cymru National Library of Wales
Illtud Daniel
> If you wanted to veto everything except jpeg files I imagine you
> would not use the veto files directive at all and simply specify:
>
> Allowed Files = /*.jpg/
Yup, that would work fine for me - ie that any 'Allowed Files'
directive implies that all non-matching files are vetoed.
Anybody else got an opinion before I dig out my K&R?
--
Illtud Daniel illtud...@llgc.org.uk
Prif Swyddog Technegol Chief Technical Officer
Jeremy Allison
> If you wanted to veto everything except jpeg files I imagine you would not use the veto files directive at all and simply specify:
>
> Allowed Files = /*.jpg/
>
>
> Veto Files = /foo.jpg/
> Allowed Files = /*.jpg/
Yes, this is pretty much how I envisaged this working...
Jeremy
Charles Marcus
>> If you wanted to veto everything except jpeg files I imagine you
>> would not use the veto files directive at all and simply specify:
>>
>> Allowed Files = /*.jpg/
>>
>> If you wanted to allow only jpeg files but not foo.jpg you would use Allowed Files and Veto Files:
>>
>> Veto Files = /foo.jpg/
>> Allowed Files = /*.jpg/
> Yes, this is pretty much how I envisaged this working...
It would be much more flexible if the use of the ! as an exception
designator was allowed for both the Allow and Veto Files options, so for
the above, you could:
Allowed Files = !foo.jpg, *.jpg
--
Best regards,
Charles
Illtud Daniel
> It would be much more flexible if the use of the ! as an exception
> designator was allowed for both the Allow and Veto Files options, so for
> the above, you could:
>
> Allowed Files = !foo.jpg, *.jpg
But now we've gone full circle, and you may as well just
extend the Veto Files syntax to allow:
Veto Files = foo.jpg, !*.jpg, *
To allow the same thing, and save us from introducting another
configuration option (assuming a first match and that matching
anything following a ! is allowed)
*Taking the suggestion that Veto Files takes precedence, and
that Allowed Files implies that all other files are vetoed, then
your requirement would be met by:
Veto Files = foo.jpg
Allowed Files = *.jpg
Although that could be confusing for a user - "why is my bar.gif
file not allowed, it's not in the Veto Files list?"
...unless there's more direction on this, I'll just (try to) implement
* above and somebdy else can throw it all out and do Something
Better. I won't have time to look at this until September at the
earliest.
--
Illtud Daniel illtud...@llgc.org.uk
Prif Swyddog Technegol Chief Technical Officer
Llyfrgell Genedlaethol Cymru National Library of Wales
Charles Marcus
> But now we've gone full circle, and you may as well just
> extend the Veto Files syntax to allow:
>
> Veto Files = foo.jpg, !*.jpg, *
This is what I meant.
Keep both options, just give them the ability to take the ! as an
exception character.
Actually, I think *all* options like this - where you can express a list
of valid/invalid items should allow the use of the ! not character. It
just adds a lot more flexibility...
--
Best regards,
Charles
Jeremy Allison
> On 8/6/2009, Illtud Daniel (illtud...@llgc.org.uk) wrote:
> > But now we've gone full circle, and you may as well just
> > extend the Veto Files syntax to allow:
> >
> > Veto Files = foo.jpg, !*.jpg, *
>
> This is what I meant.
>
> Keep both options, just give them the ability to take the ! as an
> exception character.
No, don't do this. Leave veto files alone, and just add
an "allowed files" option we can layer on top.
Jeremy.
Jeremy Allison
> But now we've gone full circle, and you may as well just
> extend the Veto Files syntax to allow:
>
> Veto Files = foo.jpg, !*.jpg, *
>
> To allow the same thing, and save us from introducting another
> configuration option (assuming a first match and that matching
> anything following a ! is allowed)
>
> *Taking the suggestion that Veto Files takes precedence, and
> that Allowed Files implies that all other files are vetoed, then
> your requirement would be met by:
>
> Veto Files = foo.jpg
> Allowed Files = *.jpg
>
> Although that could be confusing for a user - "why is my bar.gif
> file not allowed, it's not in the Veto Files list?"
>
> ...unless there's more direction on this, I'll just (try to) implement
> * above and somebdy else can throw it all out and do Something
> Better. I won't have time to look at this until September at the
> earliest.
Don't change the veto files semantics please. Just add
the "Allowed files" option.
Jeremy.
Illtud Daniel
> Don't change the veto files semantics please. Just add
> the "Allowed files" option.
Just to clear up any confusion, that's what I said. (or tried
to say).
--
Illtud Daniel illtud...@llgc.org.uk
Prif Swyddog Technoleg Chief Technical Officer
Llyfrgell Genedlaethol Cymru National Library of Wales
Jeremy Allison
> Jeremy Allison wrote:
>
>> Don't change the veto files semantics please. Just add
>> the "Allowed files" option.
>
> Just to clear up any confusion, that's what I said. (or tried
> to say).
Oh, ok - thanks. I misunderstood.
Charles Marcus
> Don't change the veto files semantics please.
It wouldn't be 'changing' the semantics, it would be adding to them.
I don't see any way adding this new 'semantic' could break any existing
installations.
--
Best regards,
Charles
Charles Marcus
> I know, but I've had a lot of experience on this, and
> I really don't want to change that code unless there
> is a known bug.
Well, thats the last word then, as I certainly won't question or second
guess you on something like that... :)
Adding Allow Files will accomplish the same thing anyway...
Jeremy Allison
> On 8/6/2009, Jeremy Allison (j...@samba.org) wrote:
> > Don't change the veto files semantics please.
>
> It wouldn't be 'changing' the semantics, it would be adding to them.
Adding is a subset of "changing" :-).
> I don't see any way adding this new 'semantic' could break any existing
> installations.
I know, but I've had a lot of experience on this, and
I really don't want to change that code unless there
is a known bug.
Jeremy.