Did I just muck up? (setfacl -x frustration)

[guermantes]

I'll spare you the rant about SSH directory/file permissions for newly created users, but I after three hours I was finally getting some hang of how to use setfacl. But it took many hours for a small thing, and I was very frustrated about the complexity of setfacl, and the fact that many tutorials online don't seem to apply to freebsd (NFS4?) I had actually solved my problem, setfacl:ing the equivalent of chmod 700 for directory logfetcher, but wanted to tidy up the ACLs for that directory (basically getting rid of the last four lines listed by getfacl), but I rushed it a tad...

Anyway, this is what I did. Look how stupidly I was placed in the tree. When the first command did not finish immediately, I freaked and Ctrl-C out. I don't know if setfacl was busy beginning to change ACLs for my entire server from the root level, or if the command just went to cyberspace since no target was specified.

Does anyone know how setfacl would have behaved without the target? Is it time for me to do a facepalm?

Code:

root@freenas:~ # setfacl -x everyone@:r-x---a-R-c--s:-------:allow
^C
root@freenas:~ # getfacl /mnt/TANK/home/logfetcher
# file: /mnt/TANK/home/logfetcher
# owner: logfetcher
# group: logfetcher
   user:logfetcher:rwx-----------:-------:allow
		 everyone@:rwx-----------:-------:deny
  group:logfetcher:rwx-----------:-------:deny
			owner@:rwxpDdaARWcCo-:fd-----:allow
			group@:rwxp--a-R-c--s:-------:allow
		 everyone@:r-x---a-R-c--s:-------:allow
root@freenas:~ # setfacl -x everyone@:r-x---a-R-c--s:-------:allow /mnt/TANK/home/logfetcher
root@freenas:~ # getfacl /mnt/TANK/home/logfetcher
# file: /mnt/TANK/home/logfetcher
# owner: logfetcher
# group: logfetcher
   user:logfetcher:rwx-----------:-------:allow
		 everyone@:rwx-----------:-------:deny
  group:logfetcher:rwx-----------:-------:deny
			owner@:rwxpDdaARWcCo-:fd-----:allow
			group@:rwxp--a-R-c--s:-------:allow
root@freenas:~ #

 

[artlessknave]

I've never even heard of setfacl. it sounds a bit like you are doing something unnecessarily micromanag-y, but taking a stab at it from the syntax, it looks like you applied your command to the contents of "~" which would be /root, as unix commands pretty much exclusively apply to the current directory if nothing is supplied (defaulting to the entire file system would kill ALOT of unix systems and be an insane idea)
you would have had to have either been working in / "root@freenas:/ #" or have ended the command with "------:allow /" to mangle your entire system, which might now even matter since freenas OS pool is essentially read only.
i would imagine you just need to find out what the proper acls for /root are and make yours match.
if all else failed, saving your config, restoring to a boot environment, and restoring your config should undo any filesystem mangling of this type.

 

[guermantes]

Thanks, I had overlooked the fact that I was in /root and not in /. That knowledge makes it easier to verify potential wrecking, of which, thankfully, there seems to be none. There was one folder with a matching rule, but it had not been deleted, so I think it shows that the command just went to cyberspace.

As for micromanaging, well I don't know, I'd be happy to be told straight if I am doing something wrong, but I can't see what that would be. Since chmod is not allowed, setfacl is what is left to use at the terminal, unless you want to boot into Windows and change the ACLs from there. Since the directory in question was not part of a SMB share or anything like that I figured I might as well use setfacl directly on the server. After all, I was only trying too get SSH login to work. I'll open another thread specifically about that topic and why ssh does not work without a bit of micromanaging (at least not for me).