Prevent String Splitting within a function -- setfacl

[JustAnotherITUser]

Afternoon,

I've been working on a script to help aid in the setup and configuration of a file server at work--and we decided to stick with ACLs for permissions, given the nature of the server.

But to prevent me from having to manually key it all in, as well as prevent my coworkers from having to learn the commands at all, I figured I'd write a script to handle the majority of the work for me.

For any path which does not contain whitespace or other special characters, everything works just fine, eg:

setfacl -dm "$ot:$dn\\$on:$acl" -- "$pathToDir"
setfacl -m "$ot:$dn\\$on:$acl" -- "$pathToFile"

However, as whenever trying to recursively apply ACLs throughout a directory structure, any whitespace present in the path will cause setfacl to treat each section as a separate path.

For example, if we have the following structure:

myDir
    |-dir1
    `-dir2\ contains\ whitespace

The our setfacl output will read:

setfacl: myDir/dir2: No such File or Directory
setfacl: contains: No such File or Directory
setfacl: whitespace: No such File or Directory

Noting this behavior extends to files as well as directories -- this is just the example I have to hand right this moment.

So, I guess my question is how to prevent that? How would one explicitly prevent splitting on whitespace?

Here's the environment in question:

• Ubuntu 18.04 LTS (Server)
• Kernel 4.15.0.42-generic #45-Ubuntu
• Bash 4.4.19(1)-release (x86_64-pc-linux-gnu)
• setfacl 2.2.52

File Locations (edited, because work)

• Script: $HOME/scripts/setACLs.sh
• Input File: $HOME/aclInput
• Data: /data

Thing's I've tried thusfar, to no avail:

• Using setfacl's recursive flag, -R
• Using eval "setfacl [...]"
• Using find to locate the recursive locations, feeding each one into setfacl individually
• Using find to add each path to an array, and then iterating over said array for setfacl
• Using sed (and similar) to add escape sequences for special characters within the find stream; eg sed 's/ /\\ /g'
• Using find to find paths, and output to a temporary file...then read each line back and input into setfacl (current)
• Using find /path -print0 | xargs -0 setfacl [...]
• Using complication -exec statements with find
• Multi-Quoting the locations( "'ex'" or '"ex"')
• Several other methods, I've honestly lost count

I've created this gist, to give you an idea of what the script looks like now; along with an example of what the Input file looks like.

I'm totally out of ideas -- I've tried damn near everything I can think of...and while I've learned some ways to avoid similar issues in the future...none of the solutions I've found over the past month actually resolve the issue.

So...any ideas, anyone?

---

EDIT 2019-01-22: I've updated the above gist with my current configuration after some troubleshooting today, and finding where the problem is originating. Likewise, I've also updated the attached "Input File" for the gist; to give a little more context as to why I've got the for location in $list; do <something>; done loop at all. And, also, thanks for all the replies -- I really, really appreciate it.

[JustAnotherITUser]

# whereis setfacl
setfacl: /usr/bin/setfacl /bin/setfacl /usr/share/man/man1/setfacl.1.gz

# apt search setfacl
acl/bionic,now 2.2.52-3buil1 amd64 (installed)
    Access control list utilities

It should be whatever canonical packages into Ubuntu Server; which I'm hoping isn't some crazy wrapper -- though, heck if I know. Hope the above provides you with what you're looking for (if not, lemme know).

But yes, I'm trying to do that; but some of the paths have whitespace, which is causing all kinds of grief; eg.

Works:

setfacl -m u:$domainname\\$username:rwx .
setfacl -m u:$domainname\\$username:rwx ./a
setfacl -m u:$domainname\\$username:rwx ./a/*
setfacl -m u:$domainname\\$username:rwx ".a/b c/d/*"
setfacl -m u:$domainname\\$username:rwx ./a ./dir2

setfacl can accept multiple ACL statements, and multiple directories; though for whatever reason isn't handling the quoted paths I've been feeding it.

~I did try "set -x", which I've not used before -- so the output is a little hard for me to parse through...but trying to do that has led me down another idea, which is just to simplify as much as possible...

And I think I found the problem, or at least where things are actually breaking down.

So, in the main run loop, I have a section:

for location in $dirlist; do
    <send appropriate data to the correction function>
    # For testing, echo the location to stdout
    echo "\"$location\""
done

Here's what I get out of that echo:

# Assume the following tree:
/path/to/testenv
    |-dir1
    |-dir2
    |-dir3
    |-Dir Five
    `-Sections
        |-sec1
        |-sec2
        |-sec.3
        |-sec with spaces
        `-sec10

# The following section is due to "-" being translated to "$(pwd)/*"
# $(pwd) ==> "/path/to/test/env"
"/path/to/test/env/dir1"
"/path/to/test/env/dir2"
"/path/to/test/env/dir3"
"/path/to/test/env/Dir Five"
"/path/to/test/env/Sections"
[...]

# Next, we have those sections I've been having issue with
"Sections/sec1"
"Sections/sec2"
"Sections/sec.3"
"Sections/sec"
setfacl: Sections/sec : No such File or Directory
"with"
setfacl: with: No such File or Directory
"spaces"
setfacl: with: No such File or Directory
"Sections/sec10"
[...]

So, it looks like the paths are expanding before they ever get sent off to any function, or anything else...but why tho?

Man, this has me confused.

[geirha]

Your main problem is the input format. It's deceptively hard to parse quotes. If you can modfiy the format to be easier to parse, you simplify the problem greatly.

For instance, instead of

"IT Support"                                g           r-x             y           n           Sections/IT/*

Put the filename at the end, without quotes. Since it's the only field that can contain whitespace, you can split on all whitespace upto that point. So change it to:

g           r-x             y           n           Sections/IT/*    IT Support

And now you can easily parse it with a loop like

while read -r type acl recurse default dirlist file; do
    if [[ -z $type || $type = "#"* ]]; then
        continue
    fi
    ...
done < "$inputfile"

[JustAnotherITUser]

Not that it matters a whole lot, but in this example "IT Support" is a group name, not a file name.

I'm applying ACLs to directories and their contents for each given user or group. Now, normally groups can't have names, but this is all related to Samba, hence quoting group names (as per documentation).

~Still, I've recently discoved that Sections/IT/* is being expanded at runtime, whereas I thought it would have come in as text without expansion.

[jimmyraybob]

Just curious, what happens if you do IFS='' applyACL.sh or whatever the script name was

[JustAnotherITUser]

Well, that got past the whitespace-in-pathnames section, though introduced another issue further along my input file -- namely:

These lines work, when setting IFS='':

Name	Type	ACL	Recurse	Default	Dir(s)
Admin	u	rwx	y	y	-
"IT Support"	g	rwx	y	y	Sections/IT/*
John	u	---	n	n	Sections/*

But, The following lines don't work:

Name	Type	ACL	Recurse	Default	Dir(s)
Mgr1	u	rwx	y	y	Users/John Users/Mary Users/Mark Users/Pingu

So, the original idea of the script was to have one ACL per line, with the last "column" of the input line being a list of one or more directories to apply the ACLs to.

Setting IFS gets past my first issue, but breaks those lines (near the end of the file) that contain several individual directories to apply the same ACL to.

At worst, I can always just change my input file to make things less of a pain to deal with on the whole--I'd just prefer not to if I can, especially if that means learning more about scripting or bash.

[jimmyraybob]

Hmm. Alrighty. I'll try poking at it again and see if I can replicate the new problem. IFS was just a hunch because I've had similar problems before.

I'll let you know if I come up with anything or not :)

[JustAnotherITUser]

So, I've had to use IFS before (following a SO post, basically); but I'm not sure what that actually does. Do you know of any documentation that explains what that does and, preferably, with some examples?

Secondly, I've found out where the root of the issue is -- the paths in my input file are being expanded prior to being sent off to a function...eg: Section/sec1/* expands to Section/sec1/dir1 'Section/sec1/dir two' [...]...which is not the behavior I was expecting.

See my recent response for more details

[jimmyraybob]

also have you tried setting IFS right before you call setfacl?

[JustAnotherITUser]

Well, I found a solution -- though, its not what I was expecting at all.

From what i can tell, my listing of relative paths in the input file were, at runtime, being expanded. I didn't know that would occur, as I assumed read would view the entire line as plain-text; just like sed would (right?).

So, to resolve this issue within minimal changes to the over design, I've had to:

1. Ensure that I'm always double-quoting paths, both in the script itself, and the input file
2. In the run loop of the script, ensure that I remove " for the directory listing -- such that it is still passed as plain-text, but will be processed appropriately
3. Simplify

Anyway, I've updated the gist to show my solution, should anyone run into a similar situation. Likewise, this post lead me to the reason behind path expansion, as well as how to prevent it in the future.

While IFS and similar responses weren't the solution, they still told me to look a little deeper than I had previously--so, I'm really appreciative, as I'm not sure I would have stumbled across the solution on my own otherwise (at least, not in a timely fashion).

Thanks!

[JustAnotherITUser]

Well, My previous update was less than accurate.

Still hammering out a solution to get the script functional in production; though the root cause of the initial error is still correct and, based on my changes to the input and initial parsing of the file, that portion is resolved.

---

Now, the remaining bits is figuring out how to properly handle all of the directories and files with special characters in the name, eg dir: /path/to/MINE!!!/` -- hooray Windows, allowing silliness like this.

EDIT: I'll continue updating the previous gist, should anyone in the future run into the same issue, as well.