by spender » Thu Apr 09, 2009 7:26 pm
I'm looking into this right now, and should have an answer for you shortly.
In case it might help others, I'm going to describe how globbed matching is implemented and how the system decides which rule to use for matching.
The globbing system does support multiple wildcard characters.
Globbed objects are "anchored" to non-globbed objects, which are generally matched by their inode/device pair.
The anchor point is determined by finding the most specific directory within the path that is fixed, for example:
If the globbed object is /home/*/blah, the anchor point is /home
If the globbed object is /home/test/*/hi/*/blah, the anchor point is /home/test
If multiple globbed objects are anchored to the same non-globbed object, they are ordered by the number of path components present in the object, so:
where /home/*/test/* and /home/* are both anchored to /home, /home/*/test/* is checked first, since it has 4 path components, while /home/* has 2.
If two globbed objects anchored to the same non-globbed object have the same number of path components, then the first object listed in your policy is the one that is checked first.
Here''s scenario to illustrate how the matching decision is made:
Suppose your policy is the following:
/home
/home/test/blah r
/home/* h
If you're opening /home/test/blah2 for reading, the system will perform the following checks:
1) does an inode/device-based object exist for /home/test/blah2 ?
2) there does not, so does an inode/device-based object exist for /home/test?
3) there does not, so does an inode/device-based object exist for /home?
4) there does. Does the inode/device-based object for /home have any anchored globbed objects?
5) it does, so iterate through the list and perform the globbed matching
6) /home/* matches /home/test/blah2, so the file is considered hidden and reading it is disallowed
-Brad