Repository navigation
[FEAT] Do not start server if $PASSWORD or $FILE__PASSWORD is present in the environment, but does not contain a usable password #207
Description
Is this a new feature request?
- I have searched the existing issues
Wanted change
Make the image fail-closed so that, when the user starts the container with environment variables that imply they desire to secure the server with a password, but the password cannot be read or otherwise has a problem (e.g. a permissions issue with the file referenced by FILE__PASSWORD), that the server does not start but, instead, fails
Reason for change
to prevent users who believe they have secured the server with a password inadvertently running it effectively passwordless. Unless you are watching your logs, you may not notice that the password was not set, but the server was started anyway.
Proposed code change
No response
Activity
github-actions commentedon Aug 18, 2025
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
LinuxServer-CI commentedon Sep 18, 2025
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
norweeg commentedon Sep 18, 2025
not sure what further information I can provide for a feature request.....
aptalca commentedon Sep 18, 2025
Perhaps explain what you mean by usable password. Provide a compose yaml with which we can reproduce the scenario you're referring to.
Currently if either of those vars are set, the auth parameters are passed to code-server with the value.
norweeg commentedon Sep 21, 2025
I did explain that. If you set FILE__PASSWORD, but the process cannot read the file (e.g. due to a file permissions issue) or the file does not exist (perhaps due to a typo in the file name), the server still starts, but without a password (fail open). The behavior should be changed to fail to start at all (fail close)
aptalca commentedon Sep 21, 2025
The title says
Do not start server if $PASSWORD or $FILE__PASSWORD is present in the environment. . .. The crucial point here is that onlyPASSWORDis a var recognized by this container specifically, but notFILE__PASSWORD.The vars that are named
FILE__blahare processed by the baseimages to set the value of envblahas the content of the file referenced. If the file is not accessible or does not exist, you get a log message stating that per https://github.com/linuxserver/docker-baseimage-ubuntu/blob/noble/root/etc/s6-overlay/s6-rc.d/init-envfile/run#L16 and no var will be set forblah.This container only cares about
PASSWORDand if it's not set, it won't enable auth.If typos are a concern, then you could misspell the var names, too, ie.
PASSWRODorFILE__PASWORD.In any case, you should always check the log when you create a new container or change the parameters.
norweeg commentedon Sep 22, 2025
I'm not saying you should protect users from EVERY possible scenario, but allowing the services to start when it is clear by the existence of a variable in the environment that the user clearly intended to have it protected by a password, but no password could be read, that the service should fail to start rather than failing open allowing open access to a service the user clearly did not intend to have open.
aptalca commentedon Sep 22, 2025
It is not clear because
FILE__PASSWORDis not a var that is recognized or tracked in this container. OnlyPASSWORDis. And in your case,PASSWORDvar is not set, as listed in the container log.norweeg commentedon Sep 22, 2025
then explain this section of README.md
Roxedus commentedon Sep 22, 2025
The FILE__ logic is not tied to the logic used to start the service. The FILE__ logic will set the variable, if the file exists, and simply just not set it if that's not the case.
LinuxServer-CI commentedon Oct 23, 2025
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
norweeg commentedon Oct 23, 2025
right. Therein lies the problem: consider the case that there was a problem reading the file (permissions issue, typo in file name, file was inaccessible on a network file system at the time the server was starting, or anything else that might cause the file to fail to be read), the system will treat this as if no password was set and start anyway without any password, exposing it to access across whatever network (up to and including the public internet) that the server is accessible from. What I am saying is that the existence of a non-null
FILE__PASSWORDenvironment variable strongly implies that the user wanted there to be a password, therefore, the startup process should exit with an error indicating a problem reading the password from file (i.e. fail-close) instead of starting without a password (i.e. fail-open).aptalca commentedon Oct 23, 2025
I don't think you understand what we're trying to tell you.
FILE__PASSWORDis not a variable recognized by this container. The container does not recognize that you're trying to set a password. All it does is, convert whateverFILE__BLAHenv var to aBLAHvar.You can set an env var
FILE__WHATEVERIWANTand it will simply attempt to set a varWHATEVERIWANT.When that type of conversion of any var fails, you get a log message. It does not matter (the code doesn't recognize or care) whether you're trying to set a password or not.
Adding a special check for
FILE__PASSWORDis not something I'm remotely interested in. The use case is too much of an edge case.With that said, feel free to customize the image to fit your needs: https://www.linuxserver.io/blog/2019-09-14-customizing-our-containers
norweeg commentedon Oct 24, 2025
no, I understood you clearly the first time, that
PASSWORDcan be set byFILE__PASSWORDbutPASSWORDis ultimately what is used. I don't think you understood my point thatPASSWORDhaving no value because the user intentionally chose to not set it andPASSWORDhaving now value because of a read error when reading from the file indicated inFILE__PASSWORDare two completely different scenarios and ought to be treated as such, but sure, maintain a fail-open configuration in this and all your images that set password in this way. You can blame the user all you want and say "don't make typos" and "watch your logs" all you want to which I say not all start-ups are interactive. Sometimes they are automated, sometimes they are at boot and sometimes file reads can and do fail for a variety of reasons, including some which the user may not have knowledge or control over (e.g. network latency/connectivity issues of a network filesystem). Clearly you want to punish users who, whether it is their fault or not, unintentionally expose their unprotected server (and its embedded terminal) to any malicious actors who may attempt to access it thinking that they had at least put a password in front of it and to condescend to anyone suggesting that fail-open is bad and could easily be changed.LinuxServer-CI commentedon Nov 24, 2025
This issue is locked due to inactivity