1

As the question says.

I have a data pool with ~ 10M files with access controlled by NFSv4 ACLs. It's usable from CLI, Samba, sometimes by daemon processes or rsync, and for some dirs by ftp/sftp, so a lot can get messed up over time. It looks okay but I can't check that size pool by eye, and I've had to fix ACLs in the past. So I'm a bit unsure whether its ACLs are as they should be, after all this time, and I'd like to check them ('audit' might be a better word) for reassurance and good practice.

As I might want to do this again in future, and it would be slow to script it file at a time, I'm hoping there's some FreeBSD utility or package specifically for this, or at least a faster way to approach it!

The ideal output would be a list of any files/dirs having different ACLs than their parent (including check on ACL ordering, ideally, since Windows is fussy, but that's less essential). Some well-defined files should have different ACLs so I'm looking for those files to appear in the results, to confirm all is fine.

What is the most efficient way to generate such a list?

Update - more info:

As @Claus_Anderson comments, the original Q wasn't specific enough as written.

My main concern is double checking myself. I want to ensure that the ACLs I've set up are working as I expect them to, which would be "everything inherits except a very few specific files". I'm being pretty restrictive, and the main risk apart from not checking carefully enough at setup, is the risk of my own actions messing something up - I access a file or dir from an incorrect uid or something stupid, or set a WSamba inherit param and forgot to remove it. Stupid but can happen. Checking ones own work matters, and I'd like to do so :)

The pool uses NFSv4 ACLs (Q updated to be clear on this). I can easily script something in shell, that runs off find, traverses the file system tree, and for every "ordinary" file+dir gets that object's ACLs and its parents ACLs, and checks if they're identical, and dumps a list of exceptions (paths of objects for which they aren't the same) into a text file. If there are many paths in that file, there'll be something clearly systematically wrong and I can fix that and recheck; if there are few then I can check by eye if they're expected or not. Once it's down to a handful of expected exceptions, I can run the script weekly via cron, and get a count by email of files added/removed/total on the list.

My concern with this is, it's just very inefficient. A dedicated utility that could directly interact with the permissions API/filing system, grab ACLs in bulk for checking as structs, and didn't have to traverse in a script and for each item generate 2 file system calls, convert to text format, then do text compare... just plain inefficient. The Unix way is to have a tool and do a dedicated job (or closely related jobs) well. While scripting could do it, it's just ghastly from an elegance/efficiency perspective unless the ACL handling side is done better (to me anyhow!). Hence I'm wondering is there a better way - meaning some standard utility, setfacl/getfacl/otheracl option, or ported package, which will make the process more efficient?

Resetting permissions would be a good way to do it, but I'd like to identify if I've made mistakes, rather than fix them but be ignorant of it. Or, since all but a few known exceptions should only have inherited permissions, traversing and listing any files+dirs found to have explicit ACLs would be a neat solution too, as it avoids a second lookup.

3
  • by ACLs do you mean simple unix permissions or also something (or things?) more complicated than that?
    – thrig
    Apr 24, 2018 at 15:08
  • By ACLs I mean NFSv4 (and probably POSIX - the question and answer would probably be identical for both) ACLs.
    – Stilez
    Apr 24, 2018 at 18:28
  • Also updated Q to clarify - thank you for the comment.
    – Stilez
    Apr 25, 2018 at 11:59

1 Answer 1

0

You make too many assumptions in your question. Should I just answer your title I would say "a script". I know of no common tools because it is not something you would commonly do.

You have the standard Unix permissions model and the Access Control Lists. The first is managed using chmod and chflags - the other using setfacl and getfacl.

I do not see you problem looking at the ACLs one at a time being a problem at all. That is the Unix way of doing things. Then you can build nice pipelines. If you only want to check if the files have different ACLs than the parent then build the pipeline accordingly.

From your question you seem to think it is obvious how you want to monitor things and keep them in place. But you do not give any specific examples. What is obvious to you is not obvious to the rest of us.

So! Do I have a script handy to solve your specific problem? No. Even if you slap on an ´awk´ tag I do not intend to write one :-)

But I do have some typical patterns:

1. Be in control

ACLs can be extremely powerful and by setting everything up with a huge attention to detail you can ensure that the permissions stay as you intend. This naturally requires that you are in charge. Using proper acls you have something much more powerful than simple user/groups. If I am the one designating control I will spend a huge effort on make sure things are set as I want. If this is the case then we should be discussing how to avoid being too permissive in a specific context. It the users are not intended to set the permissions then we should set them accordingly. Inheritence can be a challenge but it can be solved.

2. Take control

Another typical and simple approach would be to simply resetting the permissions. This comes in handy if more people have administrative access. So rather than depending on that it looks okay then define your chokepoints and reset the permissions. If you want the files to have the same permissions as the parent then go through the parents and reset the children. Any unfortunate admin who has set bad permissions will then be "helped" by the system. If this is the case the script will be a trivial list of chmod/chflags/setfacls/setuid.

3. Janitor

If you have a truly complex system with relaxed security and you need to act as the janitor and clean up in a mindful way (rather than simply taking control) then in some cases it can make sense to look into Intrusion Detection Systems (IDS). One such well-known system could be tripwire. This helps you monitoring your system and notify you if unexpected changes happen. You should in particular look at the tripwire policy twpolicy and the property p - Permission & filemode bits

auditd might also have your interest.

1
  • This is helpful. I've updated the Q to try and answer the omissions in the OP that you've highlighted. Does that help with a more focused answer?
    – Stilez
    Apr 25, 2018 at 12:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .