I'd like to make the SUID wrapper optional.

A wrapper is a binary that can be marked setuid (+s): this is not (easily)
possible with scripts (such as Perl scripts or bash scripts), so IkiWiki
generates a small C program that is compiled into a native binary and set +s.
The reason to do that is so that the IkiWiki instance that is invoked by the
wrapper runs as the user who owns the wiki's files, rather than the user
running the HTTPD.

At the moment, it's pretty much mandatory for IkiWiki to generate wrappers.
(It might be possible to prevent it by tinkering with the internal config
value `wrappers`.) I'd like to make it optional.

There are some deployment scenarios (including [[containers]]) where it isn't
necessary, and removing the requirement for a C compiler would be advantageous.

The content of the wrapper's source code is embedded across
`IkiWiki/Wrapper.pm`, which makes it hard to reason about.

One step would be to add a configuration variable to selectively disable
generating the wrappers. However, the wrappers don't just invoke IkiWiki,
they do some work (exactly what depends on several other configuration
variables). So another step will be to identify that work and, if possible,
move it out of the wrapper and into the IkiWiki instance invoked by the
wrapper.

*— [[Jon]], 2025-05-09*

> Point of support: a non-container deployment pattern that also has no
> need for suid wrappers is to store the files (and run the webserver)
> under a site-specific user account. Many of my sites do this.
>
> -- [[schmonz]]

## stuff the cgi wrapper does

1. [[genwrapper hooks|plugins/write]] (used by at least cvs and [[git]])
2. blanks the environment and selectively adds a set of variables
   back
3. adds an encoding of the `%config` hash to the variable
   `WRAPPED_OPTIONS` (with `'cgi' => 1` set)
4. drops real GID and real UID (the webserver's) by overwriting
   them with the effective values (wrapper file owner)
5. handles the logic for `CGI_OVERLOAD_DELAY`
6. takes the CGI lock
7. handles `wrapper_background_command` (which means handling
   `git_wrapper_background_command`) (which are not yet documented)
8. calls `ikiwiki` with no command-line arguments

`ikiwiki`, called with no command-line arguments, does

1. `getconfig` which populates from `WRAPPED_OPTIONS`
2. loadplugins
3. checkconfig
4. checks `$config{cgi}`, evals `IkiWiki::CGI::cgi()`

Without the CGI wrapper, we might not need 1-4 (from the first list above),
but we would need to implement 5-7, and either set up `WRAPPED_OPTIONS` or
otherwise pass the necessary arguments.

I wonder if we could move 4-6 from list 1 into `IkiWiki::CGI::cgi()`. I
guess it depends what the lock is for. It's not just a write lock, it's
part of load management. At some point I guess mutexing the loading of
the `perl` interpreter was worthwhile. I wonder if that's as much of a
problem Today.  If we loaded Perl and got as far as `IkiWiki::CGI::cgi()`,
are we still saving some heavy lifting with the lock?

*— [[Jon]], 2025-10-02*

> note that `IkiWiki::CGI::cgi()` takes the write lock (`lockwiki()`)
> fairly early on, although _after_ CGI hooks. *— [[Jon]], 2025-10-07*


## stuff the post-update hook does

1. takes the commitlock
2. clears the environment and adds back `PATH`,`HOME` and `WRAPPED_OPTIONS`
   (`'cgi' => 0`)
3. drops real GID and real UID (the webserver's) by overwriting
   them with the effective values (wrapper file owner)
4. handles `wrapper_background_command` (which means handling
   `git_wrapper_background_command`) (which are not yet documented)
5. calls `ikiwiki` with no command-line arguments

*— [[Jon]], 2025-10-04*

> Replacing the post-update hook is relatively easy. I'm experimenting
> with this in *opinionated-ikiwiki*, which already wraps the wrapper to
> do additional container-specific stuff: I've disabled generating the
> git wrapper, and extended my wrapper-wrapper to call `ikiwiki --setup… --refresh`
> instead of the wrapper. I'm happy to sacrifice support for `wrapper_background_command`
> in this configuration. *— [[Jon]], 2025-10-02*

>> Alas I've had to back this out as I had created some deadlock situations.
>> *— [[Jon]], 2026-01-07*
