Would be curious to see how would this handle demoting/downgrading permissions with the above presented syntax. Something like u=-x perhaps(?)
On Wednesday, 27 August 2014 06:15:00 UTC+2, James Cammarata wrote: > > Sticky bits and setuid/setgid all work as expected currently: > > o+t (sticky bit) > g+s (setgid) > u+s (setuid) > > The "all" target also works: > > a=rw > > As does specifying multiple targets with one operation: > > ugo=rw > ugo+x > > The special "X" mode even works, which is handy for targeting directories > only in recursive mode: > > go=rX > > When used with recurse=yes, the above would make only directories > read/execute but not files in those directories, unless they already have > the executable bit set for group/other. > > Regarding the equals and quotes, I had also tested setting the mode via a > variable that contains something like u=rw,g=r,o=r and it worked fine - the > protections against inserting extra parameters will only kick in if there's > a space in the variable along with an equals. Having an alternate syntax > might be good though, since having that many equals does make things a > little harder to read. > > The one thing we did find in our testing is that chmod on the command line > will accept something like u=+x. However our new feature only allows one > operator (equals, plus or minus) and will fail if you try to use more than > one. We can extend the module to support that syntax for absolute parity > with the CLI, however u=+x is equivalent to writing u=x (which is also > clearer and less confusing) so I don't believe it's really necessary > (others are welcome to disagree). > > > > > On Tue, Aug 26, 2014 at 7:51 PM, Michael DeHaan <[email protected] > <javascript:>> wrote: > >> Seeing James did not reply to this one, just wanted to follow up. >> >> We've discussed this a bit online, and decided the file modules need more >> examples showing how this would be specified. >> >> I find the "=" a bit confusing following an equals, but ":" might make >> things more quotey, I think we can live with it. >> >> It doesn't seem sticky bits or setuid are currently handled, but I'm open >> to it. >> >> I would hope people would use absolute modes in playbooks over things >> like +x in most cases, as it's more predictable, but it's fine if they do >> not. >> >> >> >> >> On Tue, Aug 26, 2014 at 8:39 AM, Michael DeHaan <[email protected] >> <javascript:>> wrote: >> >>> I'm not sure we're ready for this one as I'd like to have a bit more >>> discussion on it first. Maybe it's ok. >>> >>> (A) I see this is not implemented as a type='dict' sort of thing. >>> >>> file: >>> dest: /path/to/foo >>> state: tocuh >>> mode: >>> user: 'rw' >>> group: 'r' >>> owner: 'r' >>> >>> (B) I'm wondering if it would be cleaner to use "user", "group", and >>> "owner", or at least add them as aliases. >>> >>> (C) Can we tolerate mixed modes per A? >>> >>> (D) What about the other bits? >>> >>> >>> >>> On Tue, Aug 26, 2014 at 12:47 AM, James Cammarata <[email protected] >>> <javascript:>> wrote: >>> >>>> Hi all, just wanted to announce that I've merged in a PR from Paulo >>>> Bittencourt that allows the use of symbolic modes for modules like file, >>>> copy and template. For example: >>>> >>>> - name: create a new file >>>> file: dest=/path/to/foo state=touch mode=u=rw,g=r,o=r >>>> >>>> - name: modify new files permissions >>>> file: dest=/path/to/foo state=file mode=u+x >>>> >>>> Enjoy, and let us know if you see any problems with the new feature! >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Ansible Project" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected] <javascript:>. >>>> To post to this group, send email to [email protected] >>>> <javascript:>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/ansible-project/CAMFyvFis9CuY3dm7X8Ufox_RCHd1GnppBmK%3D5x8ZvoPoQ_hoxQ%40mail.gmail.com >>>> >>>> <https://groups.google.com/d/msgid/ansible-project/CAMFyvFis9CuY3dm7X8Ufox_RCHd1GnppBmK%3D5x8ZvoPoQ_hoxQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ansible Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwN0ZvAJSdOdkSyAW23BdM5vYBmKPTEffPV8K3x3Q3UKg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwN0ZvAJSdOdkSyAW23BdM5vYBmKPTEffPV8K3x3Q3UKg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/1b9bc2ee-7e20-45eb-908b-f1be3ff3afea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
