Another great security feature systemd provides is credential management[1], which allows you to expose credentials to an application in a more secure way than, say, an environment variable or a file in the filesystem.
When Vault is not available, if I’m working on a side project, for example, that’s what I always go for. Even wrote a small Go package[2] to get said credentials when your application is running inside a service with that feature.
I see we've decided to take the path of nodejs and npm, where 2-liners deserve their own package.
That's less complexity than left-pad.I thought the go culture was that dependencies are bad, and abstractions (i.e. any function calls) are confusing and bad, so it's better to just inline stuff like this and write it fresh each time you need it.
I was writing the same few lines for every project, so why not make it its own package?
For my projects I can just include the dependency, as I wrote it and don’t mind using it. Other people can copy it instead, since the proverb goes “a little copying is better than a little dependency”.
Use rust or typescript or something where it's socially acceptable to make small packages.
That'll also let you avoid writing the `if err != nil { return fmt.Errorf("context string something: %w", err) }` boilerplate again and again too (since you can just write '.context("context")?' each time).
If you're using Go, you're not supposed to build abstractions, small packages, or any sorta clever or good code. And be really careful using generics.
If you want to write abstractions, you're supposed to use a different language. Those are the rules.
Editor macros/snippets?
Didn’t think of that ¯\_(ツ)_/¯
For what it's worth this will not work properly, you have different environment variables for user and system units. Proper error handling and graceful fallback for these cases are probably worth a module here (though it could be a 10-20 liner instead too).
> you have different environment variables for user and system units
Really? I thought the point of the environment variable was it was the same, and the directory it pointed to differed depending on the service type.
I'd love a reference since at least for every systemd version I've used, you're wrong.
> Proper error handling and graceful fallback
That's application specific, so it can't really fit in a generic library well.
> I'd love a reference since at least for every systemd version I've used, you're wrong.
I must've had it confused with StateDirectory[0]. Thank you for pointing my mistake out. That does make the library a bit less useful.
[0]: https://www.freedesktop.org/software/systemd/man/latest/syst... Table 2
StateDirectory looks like it's also always the environment variable 'STATE_DIRECTORY', regardless whether it's a user or system unit, right?
works fine with both `--system` and `--user`, so seems like that's the same too.systemd's method does not require the service process to have access to the original creds file, or even the filesystem that contains it. In fact the original credentials file might even be an encrypted file and the key (and/or hardware) to decrypt it does not need to be accessible to the service process.
You completely misunderstand.
The library the person linked is to deal with systemd credentials in go.
The two lines of code I wrote are the same, and in fact are effectively 100% of the code in the library.
Oh I see.
... how exactly does it prevent inheritance to forked children?