Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cockpit-certificate-ensure: soften the certificate generation #21069

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

jmlemetayer
Copy link

I use cockpit in an embedded device, and it can happen that the power is suddenly cut off. So the file system is not synchronized and the last file system actions are lost.

If generating the self-signed certificate was one of them, you end up with empty files. And the next time you reboot, cockpit won't be able to start because cockpit-certificate-ensure will fail.

These commits prevent failure on empty files and force a new generation. In addition, we explicitly request file system synchronization after generation.

@jmlemetayer jmlemetayer marked this pull request as draft October 3, 2024 07:07
Certificate generation now works in the following cases
 - Certificate and key files do not exist.
 - Only the certificate file does not exist.
 - Only the key file does not exist.
 - The certificate file is empty.
 - The key file is empty.
@jmlemetayer jmlemetayer force-pushed the fix-cockpit-certificate-ensure branch from 4a8a6cc to e44a7b3 Compare October 3, 2024 14:39
@jmlemetayer jmlemetayer marked this pull request as ready for review October 3, 2024 14:46
@jmlemetayer
Copy link
Author

Can anyone take a look at this PR? Thanks

Copy link
Member

@martinpitt martinpitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the lag! I did an initial review. This requires some discussion still.

Thanks for looking into this!

src/tls/cockpit-certificate-ensure.c Show resolved Hide resolved
if (read_file (self->certificate_filename, &self->certificate) < 0)
return -1;

if (self->certificate.size == 0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels arbitrary and too brittle. If the concern is short writes after a power loss, then "0 bytes" feels like a "lucky unlucky" case.

The normal way to avoid that is to write the file with a temp name, fsync() it, and then rename it to the final name. Your third commit aims at that, I'll comment on that separately.

On the reading side, the gnutls functions to parse the certificate should already fail (in certificate_and_key_parse_to_creds()) if the certificate is empty, or if the file is truncated, so this check here ought to be redundant?


if (self->certificate.size == 0)
{
warnx ("empty: %s", self->certificate_filename);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likewise.

src/tls/cockpit-certificate-ensure.c Show resolved Hide resolved
src/tls/cockpit-certificate-ensure.c Show resolved Hide resolved
@@ -314,7 +314,7 @@ static const TestCase case_bad_file = {
static const TestCase case_bad_file2 = {
.files = bad_files2,

.check_stdout = "",
.check_stdout = "Unable to read*",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a symptom of the above "should go to stderr" comment. The stderr check already covers having a more precise error message.

@@ -314,7 +314,7 @@ static const TestCase case_bad_file = {
static const TestCase case_bad_file2 = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests need to be extended to cover the cases you mention (empty/truncated file and such). But let's sort out the above questions first.

src/tls/cockpit-certificate-helper.in Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants