Mailing List Archive: [Bug 3609] Support the special ${RANDOM} environment variable

https://bugzilla.mindrot.org/show_bug.cgi?id=3609

Damien Miller <djm@mindrot.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |djm@mindrot.org

--- Comment #1 from Damien Miller <djm@mindrot.org> ---
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?

I suspect $RANDOM isn't the best solution for your underlying problem.
For a start, some shells already provide this with syntax that is
incompatible with yours (e.g. https://man.openbsd.org/ksh.1#RANDOM).
Furthermore, a merely random input is only part of an effective
unique/temporary name facility.

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?

--
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs

https://bugzilla.mindrot.org/show_bug.cgi?id=3609

--- Comment #2 from Ernesto Alfonso <erjoalgo@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