That's an interesting patch, nicely done so far as it goes, but (by my
reading at least) it needs to be rethought a little to work as
expected.  There are basically two problems*:

1) Some of the allowed modes, such as g+w are actually mode _changes_,
that only specify some of the bits.  There's nothing I can see to stop
people from only partially specifying the mode.

2) The value that escapes from munge isn't canonical; the same bit
pattern could be represented in multiple ways.

The second is, I suspect, the cause of the constant resetting, as the
but the first is going to be just a much of a problem.

A couple of alternatives I can see:

* Break all the bits out as separate parameters ("owner_write",
"owner_read", etc.) and rework mode as a shorthand for setting them.
This would arguably be the most powerful (since it gives meaning to
things like o+x) but it would also be massive overkill for the common
case.

* Move the symbolic interpretation into munge and have it only accept
/^([ugoa]+)=([rwx]+)$/ or (perhaps a delimited list of them), and
return the value as if they's specified a number

* Ditto but allow /([ugoa]+)([+-=])([rwx]+)/ in the list

For the later I was thinking it would be nice if it also checked that
each bit was specified exactly once, though that makes the '-' case
problematic.  Probably you would need to pass the mask out and that
would start drifting you into an ad hoc version of the first case.

Any other approach, such as your checking the current on-disk mode in
sym2oct, is, I fear, doomed due to ordering issues.  If I were doing
it I'd probably go for a modified format, something like:

    /^a=[wrx]*|u=[wrx]*;g=[wrx]*;o=[rwx]*$/

or even (thinking of ls -l):

    /^[-r][-w][-x][-r][-w][-x][-r][-w][-x]$/

-- Markus

* It also looks from the diff as if the format check in munge will
never be reached, since it doesn't check against the regular
expression if the value is a string.  And even if it was reached it's
too broad, allowing things like "go-write-a-letter" and "giga=really
large" which I don't think you intended.

--

You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en.


Reply via email to