Bugfix: Escaped rel_path in restore_attributes() when used in grep -E regexes

[tedchirvasiu]

• My vendor_a.img contained a file named /lib64/libc++.so.
• This file had gid 0 set in fs-config (which was correct), however after repacking it would somehow end up with a gid of 2000
• I noticed rel_path in restore_attributes() would get set to the value "/lib64/libc++.so" and then used in the line:

stored_context=$(grep -E "^${rel_path} " "$FILE_CONTEXTS_FILE" | head -n1 | awk '{$1=""; print $0}' | sed 's/^ //')

• Since grep -E "^/lib64/libc++.so " would be treated as a regular expression, the ++ would get interpreted as regex characters and the whole grep expression would return nothing, thus failing to restore the original context on the file.

This PR proposes a fix. It basically just escapes the special characters in rel_path.

[ravindu644]

Awesome detective work bro!

So, This fixes the vendor bootloop issues..!

Should I revert the RSYNC change or not ?

[tedchirvasiu]

Should I revert the RSYNC change or not ?

I used the current tar version and it worked. And I imagine rsync would work too, so it's up to you if you find rsync better in general. I am too new to the Linux world to give an educated opinion on that matter.

[ravindu644]

The reason I hesitate to bring back rsync is because a guy sent me a screenshot in Telegram about a broken symlink issue when repacking an unpacked image.

These types of issues never happen when using the tar pipe method.

Tar can handle symlinks very well, no matter if they are broken or not; it handles them very well.

That's why we ship Linux rootfs inside tarballs.