Summary: | Add DBUS_MACHINE_UUID_FILE enviroment variable | ||
---|---|---|---|
Product: | dbus | Reporter: | Louis-Francis Ratté-Boulianne <lfrb> |
Component: | core | Assignee: | D-Bus Maintainers <dbus> |
Status: | RESOLVED MOVED | QA Contact: | D-Bus Maintainers <dbus> |
Severity: | enhancement | ||
Priority: | low | CC: | msniko14, smcv |
Version: | 1.5 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Add DBUS_MACHINE_UUID_FILE enviroment variable
Add DBUS_MACHINE_UUID_FILE enviroment variable or use gethostuuid() if available Add DBUS_MACHINE_UUID_FILE enviroment variable or use gethostuuid() if available |
an even better fix might use some nicer mac-specific mechanism instead of the file; I bet mac already has some kind of machine uuid thing? though this fix seems fine. the patch should use _dbus_getenv() instead of getenv(), is the only nitpick I see. Before OSX 10.6, there was no (easy) way to get machine UUID (called hardware UUID in OSX world). I added it as an option if function gethostuuid() is found. If not, we still try to use the environment variable or the default file name. I fixed getenv(). Created attachment 37989 [details] [review] Add DBUS_MACHINE_UUID_FILE enviroment variable or use gethostuuid() if available Created attachment 37990 [details] [review] Add DBUS_MACHINE_UUID_FILE enviroment variable or use gethostuuid() if available (In reply to comment #1) > an even better fix might use some nicer mac-specific mechanism instead of the > file; I bet mac already has some kind of machine uuid thing? Bug #23679 is the equivalent of this for Linux, which it seems Thiago doesn't like. Bug #42531 (Android support) has a related patch. (In reply to comment #0) > Created attachment 37923 [details] > Add DBUS_MACHINE_UUID_FILE enviroment variable As noted on Bug #42531, I think this is not necessarily safe: if you run a privileged (setuid, etc.) process, and specify a filename that it can read but you can't, then this can disclose the contents of that file. Having the machine UUID itself (as hex) as an environment variable value seems safer, from the "what's the worst that can happen?" point of view: the worst you can do to a privileged process is to trick it into thinking it's not on the same machine as the dbus-daemon. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/30. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 37923 [details] Add DBUS_MACHINE_UUID_FILE enviroment variable Right now, you can't package dbus into another application bundle (on OSX) because the dbus-daemon is still looking for the machine uuid file at the path set at compile time. I'm attaching a patch that allows to set that path at runtime using an environment variable.