On Mon, Oct 28, 2013 at 12:59 PM, John Bollinger <[email protected]>wrote:
> > > On Monday, October 28, 2013 11:54:25 AM UTC-5, Rob Reynolds wrote: > >> >> >> >> On Mon, Oct 28, 2013 at 8:42 AM, jcbollinger <[email protected]>wrote: >> >>> >>> >>> On Monday, October 28, 2013 2:55:32 AM UTC-5, Klavs Klavsen wrote: >>>> >>>> >>>> >>>> Den fredag den 25. oktober 2013 22.10.40 UTC+2 skrev Rob Reynolds: >>>> >>> [...] >>> >>>> The format could look something like the following: >>>>> >>>>> acl { 'c:/windows/temp/tempfile.txt'****: >>>>> ensure => present, >>>>> permissions => { >>>>> 'Administrators' => ['full'] >>>>> 'bob' => ['mwrx'], >>>>> 'SomeDomain\Lisa' => [x10000000,'allow','inherit','****one_level'], >>>>> 'S-5-1-18' => ['wrx','deny','inherit_**objects**_only','inherit_only'] >>>>> }, >>>>> } >>>>> >>>>> acl { 'c:/windows/temp/locked_dir': >>>>> ensure => exact, >>>>> >>>>> >>>> That one throws me.. ensure exact? I would expect 'exact' to be the >>>> same as 'present' (which in thise case is kinda odd wording- but so is >>>> exact.. who would want puppet to "almost" ensure something? >>>> >>> >>> >>> I think Klavs has an excellent point there. After some consideration, I >>> think I understand what 'exact' is supposed to mean -- that the ACL should >>> contain the specified entries *and no others* -- but the perceived need >>> for such a thing suggests that the proposed model is too high level. >>> Instead of wrapping everything up into a single Acl resource type, I think >>> you need a resource type for individual ACEs. That would also allow you to >>> ensure some specific entries present in and some others absent from the >>> same ACL, without requiring that all wanted entries be enumerated. A model >>> inspired by the Concat module might be suitable. >>> >> >> Yes, this is indeed the area I was talking about that is needing more >> discussion. >> >> Splitting to a resource type for individual ACEs might be beneficial, but >> it also might be too verbose. For an absent ACE, I was considering `'bob' >> => []`. >> >> > > But I think you need to do it. Individual ACEs are for the most part what > users want to manage. In fact, consider that every file on an NTFS file > system has an ACL no matter what. > Not completely true. It can have a NULL ACL which grants permission to everyone. > How then do the standard ensure => 'present' and ensure => 'absent' even > make sense for a resource type modeling the Acl itself? Puppet can neither > remove file ACLs nor create them; it can only manipulate them. What you > are ensuring absent or present are individual ACEs, so the model should > attach the 'ensure' parameter to individual ACEs. > I'm not convinced ACEs should be separate resources, because they don't exist outside of an ACL. For example, consider properties that extend Puppet::Property::List, like the `groups` property for the `user` resource. You specify either the complete or minimum list of groups the user should belong to, as opposed to specifying each user's group and whether the user should be present/absent from the group. > > Moreover, if ACEs are separate resources then they can be decentralized. > Suppose, for instance, that a module managing some application needs to > create a local user and grant that user permissions to access some system > directory. All is good if it can just drop an appropriate ACE in place, > but it's an awful mess if the module needs to manage a whole ACL of a > directory that doesn't belong to it. Especially so when you consider that > no resource can be declared more than once. > > > >> The actual idea on ensure present versus exact (versus the other values) >> and Windows is that there are some inherited ACEs. When you specify >> permissions, you are specifying explicit ACEs and not inherited ACEs. >> >> > > So that's a little different than I thought, which you can construe as a > clarity / intuitiveness problem if you wish to do so. > > > >> Would you always want to specify 'SYSTEM' and 'Administrators' in every >> acl or would that get old having to specify for items that are already >> going to be inherited? >> > > > No, I think the usual Puppet paradigm should apply: you specify only those > resources and properties you want to manage, and Puppet leaves everything > else alone. > > This does highlight the possibility, though, that in addition to a > resource type modeling ACEs, it may make sense to have a resource type > modeling overall ACLs, too. You could hang control of ACE inheritance > there, and perhaps there are other properties to manage that apply to ACLs > overall. > Yes, the order of ACEs needs to be specified, and is one reason why permissions cannot be modeled solely using ACEs. > > >> Are there other permissions that may already be there that you don't want >> to manage? That's really where the difference between present and exact >> came about. >> > > > Are you prepared to assume that there are not? I think that would be > unwise. > > > >> In a way of saying, I want to manage this particular set of permissions, >> plus any that are already inherited (idea of present). >> >> If you don't want to have inherited permissions on a particular ACL, >> that's where exact would come in. >> >> >>> Note too that in the Puppet universe, a parameter or value indicating >>> that unmanaged resources should be removed is conventionally spelled >>> "purge" or "purged". >>> >> >> I think I understand, but let me see if I have this correctly: >> >> acl { 'c:/windows/temp/locked_dir': >> ensure => purge, >> permissions => { >> 'Administrators' => ['full'] >> }, >> } >> >> > I think purging is something to consider, but now that I better understand > the intention of 'exact', I think the two are separate. Neither should be > overloaded onto the ensure parameter, however. Drawing on the File type as > an exemplar of a container resource, I think this would be better: > > acl { 'c:/windows/temp/locked_dir': > inherit => false, > purge => true > } > > > That says that the ACL for the specified file should not inherit ACEs from > its parent's ACL, and that any unmanaged ACEs specified directly in it > should be purged. If no ACE resources are declared for the file then it > will end up with no inherited ACEs and no ACEs of its own, either. All > four combinations of boolean 'inherit' and 'purge' values are potentially > sensible. Or actually there are six combinations, because if the 'inherit' > parameter is not declared at all then Puppet should not modify ACL > inheritance, thus that constitutes a separate value. > > > > >> Additionally, although POSIX ACEs are unordered, it is my understanding > that the order of ACEs within a Windows ACL is significant. If that is > indeed correct then I don't see how the proposed model accounts for it. > >> >> Yes, you are correct. We're talking about this and whether the module >> should reorder appropriately for the order in some cases. We've talked >> about an array instead of a hash for ACEs. >> >> > > > The needed order is whatever the user says it is, so for the module to > "reorder appropriately", it has to offer some means for the user to declare > that order. > > So, an array then. But an array of what, exactly? Your hash values are > already arrays themselves -- whose meanings are largely opaque to me, by > the way -- so will you now have an array of arrays? An array of hashes > would be more self-documentary, but wait: those inner hashes now bear a > strong resemblance to resource declarations. Why was it, again, that you > didn't want a separate resource type for ACEs? > > Note, too, that whatever ordering mechanism you choose, you'll still have > to decide how to deal with ordering relative to unmanaged ACEs. Probably > there's some room there for a smart implementation to figure something out, > but there still ought to be a mechanism for the user to exert influence > here. > Good point. Windows has a preferred ordering for inherited vs non, and allow vs deny ACEs, and we will need to take unmanaged ACEs into account. -- Josh Cooper Developer, Puppet Labs -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CA%2Bu97um01MQHq8r0TYdWLxyUFZA2tL5nYw7TLC0bSzjC-4nfGg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
