A different way of managing POSIX ACLs : fooacl

153 views
Skip to first unread message

Matthias Saou

unread,
Dec 17, 2013, 6:10:20 AM12/17/13
to puppet...@googlegroups.com
Hi,

I have just published the module I use to manage POSIX ACLs : fooacl

I don't consider it the cleanest possible approach to the problem, but
it's very efficient and flexible. I would actually call it a hack :-)

There's room for improvement, such as splitting out Execs per managed
path to avoid useless re-applying on unchanged paths, or using file
snippets without concat to avoid depending on that module. Pull
requests are more than welcome :-)

I'll publish it to the forge shortly, too.

https://github.com/thias/puppet-fooacl

Short extract of the README :

--
Most (all?) other ACL modules implement a type which can be declared
only once per file, which isn't flexible. This module takes the unusual
approach of creating a single large concatenated script to manage all
ACLs recursively in a single run. Ugly, yet very efficient and flexible
since ACLs aren't tied to the file type in any way.

Features :

* Set ACLs for the same path from different parts of your puppet
manifests (flexible).
* Set global ACL permissions to be applied for all paths managed by
the module (flexible).
* Automatic purging of ACLs on paths as long as at least one ACL is
still being applied by the module (remove users easily and
reliably).
* Automatic setting of both normal and default ACLs to the same values
(shortens declarations, increases code readability).
--

Feedback welcome!

Matthias

--
Matthias Saou ██ ██
██ ██
Web: http://matthias.saou.eu/ ██████████████
Mail/XMPP: matt...@saou.eu ████ ██████ ████
██████████████████████
GPG: 4096R/E755CC63 ██ ██████████████ ██
8D91 7E2E F048 9C9C 46AF ██ ██ ██ ██
21A9 7A51 7B82 E755 CC63 ████ ████

jcbollinger

unread,
Dec 17, 2013, 9:59:16 AM12/17/13
to puppet...@googlegroups.com


On Tuesday, December 17, 2013 5:10:20 AM UTC-6, Matthias Saou wrote:
Hi,

I have just published the module I use to manage POSIX ACLs : fooacl

I don't consider it the cleanest possible approach to the problem, but
it's very efficient and flexible. I would actually call it a hack :-)



But cool, nonetheless.  It has many of the features I would hope to see in such a module.

 
There's room for improvement, such as splitting out Execs per managed
path to avoid useless re-applying on unchanged paths, or using file
snippets without concat to avoid depending on that module.



Or a way to detect and reject inconsistent ACL entry declarations.  Or a way to leave unmanaged ACL entries alone while managing other entries in the same files' ACLs.  Even with a few holes, though, it's still better than anything else I'm aware of in that space.  Nice work!


John

Reply all
Reply to author
Forward
0 new messages