11 March 2024 at 19:00, "Bollinger, John" <[email protected]> wrote:
> > I think you're overthinking it. > > At any given time, the BDS conformance of any process, whatever its role, > should be evaluated in terms of *its own* environment. Even if that didn't > make abundant sense, there really isn't any other viable alternative for a > specification relying so fundamentally on environment variables. > > System services are no exception. Consider that even if a service could > determine the value of, say, the XDG_CACHE_HOME variable of a client process, > chances are poor that the service could access the designated directory even > if it wanted to do. And it would be an enormous security vulnerability if it > could and did. > > Bear in mind also that even different processes running strictly by, as, and > for a particular user don't have to have the same values for their > BDS-relevant environment variables. In this sense too, BDS is inescapably a > per-process specification. Gotcha. That is a bit annoying then for things like SSH and VNC servers, whose server processes look for per-user configuration for the user being accessed through those server protocols. I suppose, then, that the next best thing would just be to provide as much configurability for the server programs in order to specify alternative file/dir paths for per-user configuration, i.e. also looking for a ~/.config/vnc/passwd file as opposed to only ~/.vnc/passwd. Of course, this would mean that such paths would have to be hard-coded, however it wouldn't be too difficult to delegate such server config to a shell script or the like running with elevated privileges, i.e. through sudo, in order to then have an environment variable value to reference from the running login shell. I appreciate the response. Kind regards.
