Re: [lmi] Finding many, many user-but-not-group-writable files in install scripts

[Greg Chicares]

On 6/12/22 19:57, Vadim Zeitlin wrote:
> 
>  This is not the most crucial question right now, but I wonder about the
> find command at the end of install_wx*.sh, added back in c4749b3eb (Work
> around an autotools anomaly, 2020-05-13). This command is preceded by a
> comment saying that it should find zero files but, in practice, it finds
> thousands of files to me, which is mildly annoying when looking at the logs
> (or more than mildly when doing it on the web, where viewing such huge logs
> is slow) and, of course, rather unexpected.

Suppose two users, A and B, both work on the same corporate server,
in the same $prefix, and both are members of group L. If A builds
in prefix="/opt/lmi", and later B goes there and tries to rebuild,
then B's rebuild may fail when it tries to overwrite files (e.g.,
'.o' files in a build directory) that were written by A--because
A owns those files, and B lacks write access to A's files. That's
the problem this was intended to solve.

Now, if all the files that can possibly be created by running lmi's
makefiles and scripts have group-id L, and extend read and write
privileges to all group members, then A and B can read and write
all those files. Then the problem no longer arises.

Anyway, that was the dream, and I believe it actually worked--until
we started using git submodules, which didn't respect the group and
permission flags that were to be inherited by any file created in
/opt/lmi/**/ . By that time, I had forgotten whatever I'd learned
about set-gid bits on parent directories, and I didn't spend time
trying to fix it because it looked daunting and I had other things
to do.

You've said, probably more than once, that $prefix should not be
hardcoded. I'm sure that's a worthy goal, but the fact is that it
is hardcoded, all over the place: "sedimentation" has occurred,
and dis-encrusting everything while introducing zero new defects
is a nightmarish task. Besides, there might be a circumstance
in which A would wish to update B's build (or there might not,
but that's a hard thing to figure out).

>  The trouble is, I don't understand why isn't it supposed to find all the
> files it finds, e.g. all of the files created while building wxWidgets
> under /opt/lmi/local/gcc_x86_64-pc-linux-gnu/wx-ad_hoc/lmi-gcc-11 or
> similar directory. These files are not affected by the chmod calls just
> above and it seems perfectly normal for them to have the default 644 mode
> (corresponding to the standard 022) umask.

I thought they'd respect the set-gid bits I'd set on their parent
directories. IIRC, the issue was that autotools didn't do that,
or git submodule updates didn't...or maybe neither did.

> I could change the umask, but

I've done that, in various places, as shown by `git grep umask`:

gwc/.zshrc:umask g=rwx
lmi_setup_11.sh:umask 0007
lmi_setup_inc.sh:umask g=rwx

> I'd rather not, to be honest, especially because I just don't see any
> reason to run this find command on the entire prefix directory. Why don't
> we restrict it to just the directories where files are actually getting
> installed? Or, at least, exclude, all the build directories (although I
> don't know how would we identify all of them in general, but even just
> excluding "/opt/lmi/local/gcc_*" would be already good -- if I do this, the
> number of found files is reduced from 2092 to 2, /opt/lmi/local and
> /opt/lmi/local/include)?

The goal is not to mask anomalies, but to prevent them. I'm not sure
we should abandon the "dream" above. If, someday, we make time to go
back and regain it, this 'find' command is a ready-made test case.

>  Am I missing something or could we please make this change?

I fear that would be to turn a blind eye to anomalies that are now
identified to us, which might cause us difficulties tomorrow.

But as you started out by saying:

>  This is not the most crucial question right now

and right now I'm not sure what the real goal should ideally be;
or how much effort it would take to achieve; or what, if anything,
we should do right now.