Files
lmxopcua/tests/Server/ZB.MOM.WW.OtOpcUa.Host.IntegrationTests/SecretsStorePathValidationTests.cs
T
Joseph Doherty b037cc7ac4
v2-ci / build (push) Successful in 4m42s
v2-ci / unit-tests (push) Failing after 15m19s
chore(secrets): adopt ZB.MOM.WW.Secrets 0.6.2 — fail-closed store-path validation
Four-minor jump 0.2.3 → 0.6.2. The release line exists because a deploy
renaming the app directory took the MxGateway credential store with it
(2026-08-09, two silent days): Secrets:SqlitePath must now be absolute AND
outside the content root, rejected at boot rather than relocated. 0.6.2 over
0.6.1 is message-only (the rejection text now teaches the mounted-volume
case and forecloses the override hunt) — the live rig evidence below was
gathered at 0.6.1 and the validator behavior is identical.

Adoption changes beyond the pins:

- appsettings.json drops the relative "otopcua-secrets.db" (now boot-fatal);
  dev gets the library's absolute per-user default, deployments supply their
  own (wonder already pins an absolute out-of-root path in the service env).
- Program.cs's pre-host ${secret:} expander now calls the FOUR-argument
  AddZbSecrets with builder.Environment.ContentRootPath. This call site is
  the actual fix, not the pin: the throwaway container has no
  IHostEnvironment, and without the explicit root the under-content-root
  rule is skipped at exactly the moment the migrator creates the store file
  (the 0.6.0 defect). Do NOT simplify back to the 3-argument overload — it
  compiles and silently reopens the gap. Pinned by a Program.cs source-scan
  test AND a runtime falsification control that RUNS the migration and
  demonstrably creates the store at the rejected path under the 3-arg form.
- docker-dev: Secrets__SqlitePath moves /app/data → /data via a SECOND mount
  of the same per-node volume (same file at the volume root, so seeded
  stores carry over) because /app is the container's content root and the
  new rule correctly rejects it. LocalDb stays on /app/data (secrets-only
  rule).
- SecretsStorePathValidationTests: positive-control probes, artifact-first
  (relative and in-content-root paths must FAIL leaving no file; outside-
  root passes; the no-explicit-root control proves the file assertions can
  fail) — a clean boot is equally consistent with the validator never being
  wired.

Live-verified on the six-node docker-dev rig (at 0.6.1): all nodes boot
under the new validation with stores at /data; an AdminUI-written secret
converged into BOTH central nodes' independent stores; site-a held only its
own pair's secrets (Phase 6 pair-local isolation intact). Replicator wire
behavior unchanged 0.3.0–0.6.x per CHANGELOG; registration-graph pins and
the full suite pass.
2026-08-11 09:06:43 -04:00

153 lines
7.5 KiB
C#

using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.FileProviders;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Options;
using Shouldly;
using Xunit;
using ZB.MOM.WW.OtOpcUa.Host.Configuration;
using ZB.MOM.WW.Secrets;
using ZB.MOM.WW.Secrets.DependencyInjection;
using ZB.MOM.WW.Secrets.Sqlite;
namespace ZB.MOM.WW.OtOpcUa.Host.IntegrationTests;
/// <summary>
/// Positive-control probes of the Secrets 0.6.x fail-closed store-path validation as composed by
/// THIS host — a clean boot is equally consistent with the validator never being wired, so the
/// load-bearing assertions here are the rejections (the approach that caught the library's own
/// 0.6.0 pre-host hole during the family adoption). Covers both compositions the host has:
/// <list type="number">
/// <item>in-host via <c>AddOtOpcUaSecrets</c> (an <see cref="IHostEnvironment"/> supplies the
/// content root);</item>
/// <item>the pre-host <c>${secret:}</c> expander shape from <c>Program.cs</c> — a bare
/// <see cref="ServiceCollection"/> with NO <see cref="IHostEnvironment"/>, where the content
/// root must be passed explicitly or the under-content-root rule silently vanishes at exactly
/// the moment the migrator creates the store file (the 0.6.0 defect).</item>
/// </list>
/// </summary>
public sealed class SecretsStorePathValidationTests : IDisposable
{
private readonly string _contentRoot =
Directory.CreateTempSubdirectory("otopcua-secrets-croot-").FullName;
public void Dispose()
{
try { Directory.Delete(_contentRoot, recursive: true); } catch { /* best effort */ }
}
private static IConfiguration ConfigWithPath(string sqlitePath) =>
new ConfigurationBuilder().AddInMemoryCollection(new Dictionary<string, string?>
{
["Secrets:SqlitePath"] = sqlitePath,
["Secrets:MasterKey:Source"] = "Environment",
["Secrets:MasterKey:EnvVarName"] = "ZB_SECRETS_MASTER_KEY",
["Secrets:RunMigrationsOnStartup"] = "false",
}).Build();
private ServiceProvider BuildHostShapedProvider(string sqlitePath)
{
var services = new ServiceCollection();
services.AddLogging();
services.AddSingleton<IHostEnvironment>(new FakeHostEnvironment(_contentRoot));
services.AddOtOpcUaSecrets(ConfigWithPath(sqlitePath));
return services.BuildServiceProvider();
}
[Fact]
public void A_relative_store_path_is_rejected()
{
using var sp = BuildHostShapedProvider("otopcua-secrets.db");
var ex = Should.Throw<OptionsValidationException>(
() => sp.GetRequiredService<IOptions<SecretsOptions>>().Value);
ex.Message.ShouldContain("absolute", Case.Insensitive,
"the rejection must name the rule, or the operator who caused it cannot act on it");
}
[Fact]
public void An_absolute_path_inside_the_content_root_is_rejected()
{
// Absolute does NOT imply safe — this is the MxGateway outage shape: the path that lost
// the credential store WAS absolute; it sat in the directory the deploy renames.
var inside = Path.Combine(_contentRoot, "data", "otopcua-secrets.db");
using var sp = BuildHostShapedProvider(inside);
var ex = Should.Throw<OptionsValidationException>(
() => sp.GetRequiredService<IOptions<SecretsOptions>>().Value);
ex.Message.ShouldContain("content root", Case.Insensitive);
File.Exists(inside).ShouldBeFalse("a rejected path must never gain a store file");
}
[Fact]
public void An_absolute_path_outside_the_content_root_passes()
{
// The control for the two rejections above: proves the failures fail because of the RULES,
// not because the whole subsystem is unresolvable in this composition.
var outside = Path.Combine(Path.GetTempPath(), $"otopcua-secrets-{Guid.NewGuid():N}.db");
using var sp = BuildHostShapedProvider(outside);
sp.GetRequiredService<IOptions<SecretsOptions>>().Value.SqlitePath.ShouldBe(outside);
}
[Fact]
public async Task The_prehost_expander_rejects_an_in_content_root_path_before_creating_the_store()
{
// Mirrors Program.cs's ${secret:} expansion container byte-for-byte: bare ServiceCollection,
// no IHostEnvironment, content root passed EXPLICITLY (the 0.6.1 four-argument overload),
// then RUN the migration — resolving the migrator alone never touches the filesystem, so a
// resolve-only probe leaves the file assertions vacuous. The rejection must land BEFORE
// creation: an empty store with -wal/-shm at the rejected path is the artifact that made
// the MxGateway outage read as "the database is there, it's just empty".
var inside = Path.Combine(_contentRoot, "data", "otopcua-secrets.db");
await using var sp = new ServiceCollection()
.AddZbSecrets(ConfigWithPath(inside), "Secrets", _contentRoot)
.BuildServiceProvider();
// Record rather than Should.Throw, so the ARTIFACT is asserted first: a regression that
// stops the throw but still writes the store must fail on the file — which is the defect —
// not on a missing exception that never mentions the database at the rejected path.
var ex = await Record.ExceptionAsync(() =>
sp.GetRequiredService<SqliteSecretsStoreMigrator>()
.MigrateAsync(TestContext.Current.CancellationToken));
File.Exists(inside).ShouldBeFalse("a rejected path must not be left holding a store file");
File.Exists(inside + "-wal").ShouldBeFalse();
File.Exists(inside + "-shm").ShouldBeFalse();
ex.ShouldBeOfType<OptionsValidationException>();
}
[Fact]
public async Task Without_the_explicit_content_root_the_prehost_hole_reopens()
{
// Falsification control for the test above, and the reason Program.cs's four-argument call
// is load-bearing: the same composition WITHOUT the explicit root has no IHostEnvironment
// to consult, the under-content-root rule is skipped, and the migration WRITES the store at
// the rejected path. Running the migration (not just resolving) is what makes this a true
// control — it proves the file assertions above are capable of failing. If the library ever
// closes this differently (making this test fail), the source-scan pin on Program.cs can be
// retired with it.
var inside = Path.Combine(_contentRoot, "data", "otopcua-secrets.db");
await using var sp = new ServiceCollection()
.AddZbSecrets(ConfigWithPath(inside), "Secrets")
.BuildServiceProvider();
await sp.GetRequiredService<SqliteSecretsStoreMigrator>()
.MigrateAsync(TestContext.Current.CancellationToken);
File.Exists(inside).ShouldBeTrue(
"the 3-argument overload with no IHostEnvironment must create the store at the "
+ "in-content-root path — the exact hole the explicit content root closes");
}
private sealed class FakeHostEnvironment(string contentRoot) : IHostEnvironment
{
public string EnvironmentName { get; set; } = "Production";
public string ApplicationName { get; set; } = "OtOpcUa.Tests";
public string ContentRootPath { get; set; } = contentRoot;
public IFileProvider ContentRootFileProvider { get; set; } = new NullFileProvider();
}
}