https://bugzilla.mindrot.org/show_bug.cgi?id=3609
--- Comment #2 from Ernesto Alfonso <erjoa...@gmail.com> ---
> How would this actually work? $RANDOM doesn't end up anywhere usable other
> than the listening path on the remote side. Do you enumerate all paths there
> to figure out which one?
On the remote side the client program can use a glob like
/tmp/.x-service-*.sock. This is possible because I can control where
within the RemoteForward path the ${RANDOM} gets inserted.
> I suspect $RANDOM isn't the best solution for your underlying problem.
The solution certainly works for me but if you have a better suggestion
I would be open to it.
> For a start, some shells already provide this with syntax that is
> incompatible with yours (e.g. https://man.openbsd.org/ksh.1#RANDOM).
Not sure I follow. I installed ksh and `echo ${RANDOM}` worked as
expected, how is that syntax incompatible?
> Furthermore, a merely random input is only part of an effective
> unique/temporary name facility.
That is exactly how the feature would be useful to me.
> Would an explicit unique/temporary name facility for forwarded Unix domain
> sockets be better? There is already an analogous thing for remote-forward
> ports, where a listener port number of 0 indicates that the server should
> allocate one and tell the client what it picked. We could do something
> similar here (say when passed an empty listen pathname). Would this work for
> you?
On the remote side I need to know where to look, so binding to a random
port or wouldn't be very useful. That is the reason I am using unix
sockets with a regular, globabble pattern and a fixed prefix.
--
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
