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!
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?
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.
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).
Would be curious to see how would this handle demoting/downgrading permissions with the above presented syntax.
Something like u=-x perhaps(?)
Yeah, we definitely need some examples in the “EXAMPLES” block of the file module at least for this.
The copy module could refer to them.
Dan, the syntax u=-x is not currently supported, but if you look at the way chmod operates that essentially boils down to “u=” (which removes all permissions) and then “-x” (which removes the execute bit from the last target specified - which is user). So really you’re wiping the permissions for the given target. Here’s an example using chmod on the CLI (on linux, maybe the BSDs or other Unix systems are different?):
$ chmod 777 /tmp/foo.txt
$ chmod u=-x /tmp/foo.txt
$ ls -l /tmp/foo.txt
----rwxrwx. 1 root root 0 Aug 26 11:05 /tmp/foo.txt
Which has removed all permissions for the owner of the file, not just the execute bit. If you’re trying to just remove the execute bit, the proper syntax would just be u-x:
$ chmod 777 /tmp/foo.txt
$ chmod u-x /tmp/foo.txt
$ ls -l /tmp/foo.txt
-rw-rwxrwx. 1 root root 0 Aug 26 11:05 /tmp/foo.txt
The new symbolic modes work fine using the minus sign to remove permissions, you just can’t specify to operators at the same time.
I had added some examples to the docs, however I can definitely add more.