$HOSTNAME is the name of the VM.
Of course as a user the hostname will often appear in a window’s title bar and in the command prompt if you’re looking at console/terminal
Unfortunately this isn’t the case in whonix vms.
I just fired up a Whonix qube (I don’t use it much, to be honest).
Title bar reads [disp9174] Whonix Welcome Page ___ Tor Browser. (I am using KDE; that could make a difference.)
But you are right in that at the command prompt in that qube the name (both in the prompt and echoing $HOSTNAME) is simply “host.” Nor is any other environment variable set to include (in this particular instance) 9174 so there might not be a way to figure this out.
This is probably to increase anonymity. Anyone asking their visitor for a hostname just gets “host” like all the other whonix/tor/whatever clients.
For the application I was working, unfortuntely, I expect to be running offline and so whonix wasn’t a consideration. Sorry about that.
That’s alright, I think I’m going to go with the Admin API which gives me access to the disposable name.
Are there any security risks that I’m introducing by allowing access to admin.vm.CreateDisposable from a networked VM (other than the aforementioned issue of creating a massive number of disposables)? I guess I’m essentially expanding the trusted computing base to now include the code that is responsible for serving admin.vm.CreateDisposable in dom0, but other than that nothing new is being introduced.
Is this correct?
Yes: qubesdb-read /name
Also see qubesdb-list / for other things that dom0 makes available to the VM.
None that I can see from a quick glance at the implementation in /usr/lib/python3.8/site-packages/qubes/api/admin.py, FWIW.