The workflow went in at severity: error on the assumption that a
never-linted repository would have a backlog worth grandfathering. It
did not -- error found nothing, and warning found exactly two things, so
the cautious setting was protecting against a problem that was not
there.
zimbra_backup.sh: SC2024, sudo does not affect redirects. The
`> "$BACKUP_FILE"` runs as root rather than as the sudo'd zimbra user,
so backups landed root-owned inside a directory the script deliberately
chowns to zimbra:zimbra. Kept the redirect -- root can always write
there, and piping into `tee` would put tee's status in $? and hide a
zmmailbox failure -- and handed ownership over explicitly afterwards.
The suppression is narrow and states why.
disk_cleanup.sh: SC2034, total_freed was assigned and never read.
CI now holds at warning with a clean tree, so anything that trips it is
new rather than inherited.
Both scripts built a command string by interpolating user input into
bash -c:
sudo -u zimbra bash -c "... -m '$EMAIL' ..."
The single quotes inside the double-quoted string are not protection --
the outer shell expands $EMAIL first. An address of
x' ; id ; echo '
closes the quote and runs arbitrary commands. Both scripts require root
and invoke this through sudo -u zimbra, so injected commands execute as
the account that owns the entire mail store. Verified against the exact
quoting pattern before and after the change.
Fixed by single-quoting the script body so nothing is interpolated, and
passing values as positional arguments. The bash -c wrapper is kept
deliberately rather than calling zmmailbox directly, since it may depend
on shell setup and this could not be tested against a live Zimbra.
Two related holes in the same input paths:
- $EMAIL is also part of the backup filename, so a "/" wrote outside
$BACKUP_DIR. Now validated as a plain address.
- The restore prompt took a filename and concatenated it into a path, so
"../../etc/shadow" escaped $BACKUP_DIR. Now rejects anything
containing a separator.
Also switched the backup listing from `ls | grep "$EMAIL"` to a find
with grep -F: unquoted the address was treated as a regex, so "." in it
matched any character.