Homed bulk directories v2

[AdrianVovk]

This is a reimagined approach for #30646, as I described in this comment

Depends on #31004

Fixes: #18323

[AdrianVovk]

Unforeseen issue I ran into w/ this approach: signatures

Right now the code works something like this. If a caller wants to change the bulk directory, they add bulkDirectory to the regular section. This is passed through homed into homework. homework then calls user_record_steal_bulk_dir, which extracts the value of bulkDirectory from the record (making sure to purge it from the JSON). homework then does the bulk directory replacement/reconciliation magic. Finally, homework returns the new JSON (now lacking bulkDirectory, with a possibly updated binding and so on) back up to homed, which writes it to disk.

So here's the problem: Before handing the JSON record into homework, homed signs it first. This signature happens before homework strips the bulkDirectory out of the record. So when homework does strip out the field, the record no longer matches the signature.

This all also brings in a natural follow-up question: should the contents of the bulk directory be signed into the user record?

Couple ideas on how to solve this:

• Exclude bulkDirectory from the signature
• Make clients pass an updated bulkDirectory into homed through the status section
• Make a new section transient that behaves like secret but is for non-sensitive information
• Sign the record after homework is done with it, to allow homework to manipulate the record however it wishes (I think this is personally my favorite solution)

[poettering]

So for various fields we allow overriding via the binding section.

I think a scheme where we have one of these dirs declared in the regular user record, and then overriden with the copied out version in the binding section does make sense to me.

thta would would mean clients would always have to check the binding first, and only when not set use the original one. but we do something similar with homeDirectory itself already, it's automatically resolved when parsing.

[poettering]

btw, should we really name this "bulk"? i.e. is that really descriptive enough? it's just saying something about the size. But I think its more important to say something about the public exposure of the data contained in there. Hence maybe publicResourceDirectory?

[poettering]

I'd probably not try to hide the updating of the bulkdir in the updating of the record, but keep that a separaze operation, where you just pass in an fd to a temporary dir with the new bulkdir, and homed does the replacement.

[poettering]

I am still not onboard with moving the identity file down one level. This just opens uip the door to various vulnerabilities with symlinks.

i.e. people could then replace .identity/ with a symlink to anything they like and a simple O_NOFOLLOW when opening the identity file won't suffice anymore to avoid being tricked. i.e. the tough bit here is that privileged code is going to access this, and we should not make it easy for an evil user to trick priv code to read stuff it shouldn't read, and trusting it because the object's perms actually indicate its owend by root. but in reality somebody just redirected things via symlinks.

[poettering]

please rebase

[poettering]

i don't like the passing down of the flags field still

[poettering]

let's get this baby landed.

[poettering]

please fix those error return things, and we are good to go.

[AdrianVovk]

CI failures appear unrelated:

• mkosi / ci (fedora, rawhide) (pull_request):

Transaction failed: Signature verification failed.
PGP check for package "filesystem-3.18-8.fc40.x86_64" (/var/cache/libdnf5/fedora-306b6523e9c8dc02/packages/filesystem-3.18-8.fc40.x86_64.rpm) from repo "fedora" has failed: Import of the key didn't help, wrong key?

• All of the rest:

<snip>
TEST-75-RESOLVED:                   FAIL     ( 66 s)
<snip>
TOTAL FAILURES: 1 OF 64

[bluca]

too many failures for comfort, I've hit the rebase button for another run

[AdrianVovk]

🎉 Thank you!