<div dir="ltr"><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Il giorno lun 3 ago 2026 alle ore 15:11 Erich Ritz via SlackBuilds-users <<a href="mailto:slackbuilds-users@slackbuilds.org">slackbuilds-users@slackbuilds.org</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sunday, August 2nd, 2026 at 5:48 PM, B. Watson <<a href="mailto:urchlay@slackware.uk" target="_blank">urchlay@slackware.uk</a>> wrote:<br>
<br>
> <br>
> RFC for new find/chmod in the SBo templates<br>
> ===========================================<br>
> <br>
> Please respond to this, if you have any opinion at all (for or<br>
> against the proposed change).<br>
> <br>
> The existing template code:<br>
> <br>
> ----------------------------------------------------------------------<br>
> find -L . \<br>
> \( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 \<br>
> -o -perm 511 \) -exec chmod 755 {} \; -o \<br>
> \( -perm 666 -o -perm 664 -o -perm 640 -o -perm 600 -o -perm 444 \<br>
> -o -perm 440 -o -perm 400 \) -exec chmod 644 {} \;<br>
> ----------------------------------------------------------------------<br>
> <br>
> The proposed replacement code:<br>
> <br>
> ----------------------------------------------------------------------<br>
> find . ! -type l -a \<br>
> \( -perm /111 -a ! -perm 755 -a -exec chmod -f 755 {} + \) -o \<br>
> \( ! -perm /111 -a ! -perm 644 -a -exec chmod -f 644 {} + \)<br>
> ----------------------------------------------------------------------<br>
> <br>
> English translation:<br>
> <br>
> For all files or dirs under the current directory:<br>
> <br>
> ...if it's a symlink, ignore it completely.<br>
> <br>
> ...if any of the +x bits are set (owner group other), but the mode<br>
> is not already 755, set the mode to 755 (-rwxr-xr-x).<br>
> <br>
> ...else, if no +x bits are set, but the mode is not already 644,<br>
> set the mode to 644 (-rw-r--r--).<br>
> <br>
> ...else, the mode was already 644 or 755, so don't change anything.<br>
> <br>
> Explanation and notes:<br>
> <br>
> Because of the + in the -exec, the filenames are all passed<br>
> as arguments to the same instance(s) of chmod, rather than<br>
> executing a separate chmod for each file. This is faster and less<br>
> resource-intensive: we only spawn 0, 1, or 2 chmod commands, no<br>
> matter how many files need changing.<br>
> <br>
> We don't want to use -L (follow symlinks), because what if someone<br>
> creates a tarball with a symlink to /etc/shadow or /root? The<br>
> old template would 'chmod 644 /etc/shadow' or 'chmod 755 /root'!<br>
> Using "! -type l" omits symlinks entirely, which makes more sense<br>
> and is safer. Plus, symlinks' permissions aren't even used by the OS<br>
> (or changeable); the permissions of the symlink *target* are used.<br>
> <br>
> The -f in the chmod command is probably redundant: it tells chmod<br>
> to always return success status, even if it failed to change the<br>
> permissions of one or more files. This is to avoid the script dying<br>
> due to "set -e". In my experience, chmod when run as root normally<br>
> only fails if it's passed a broken (dangling) symlink... which will<br>
> not happen here because of the "! -type l".<br>
> <br>
> All the -a's are actually redundant: find assumes assumes -a (logical<br>
> AND) by default. I left them in because I think it's more readable<br>
> that way. Overall, I think this is more readable and easier to<br>
> understand than the old template.<br>
> <br>
> This also is more reliable than the old template, which listed<br>
> explicit permissions (-perm 777 -o -perm 775 -o -perm 750, etc)<br>
> but the lists were incomplete. Files with mode 710, 510, 500, or 751<br>
> wouldn't get their permissions changed, for example.<br>
> <br>
> I've been using this new find/chmod template for my own SlackBuilds<br>
> for about a year now, to test the waters, and I've had no problems.<br>
<br>
My only suggestion would be IF this change is made to also update all builds that exactly match the old style to the new style. From what I remember we are encouraged to use the templates in case changes like this are made then we can easily be updated to the new style.<br>
<br>
The assumption here is that if an existing build uses exactly the same lines in the template then the script maintainer is saying "I'm following the spirit of the template and just want done what the template is doing here" and therefore would want any improvements to the template applied. If an existing build does not exactly match the template, then that indicates a conscious effort on the script writer to deviate away from the template for some reason, and therefore a conscious effort must be applied (if desired) to update to the new style.<br>
<br>
Erich</blockquote><div><br></div><div><div>if we decide to intervene on all the scripts we shouldn't do
massive changes like this during the normal update cycle or we break
every existing fork (like mine, for example).</div><div><br></div><div>the
moment to intervene in this cleanly is when we move to a different
version of Slackware and submissions are closed and external branches
merged: only then we should also adapt existing scripts to eventual new templates, not before.</div><div><br></div><div>Matteo</div> </div></div></div>