What to do about rcmdsh(3) ?

[Eitan Adler]

Now that the rcmds are removed from base, it opens a question about
what to do with rcmdsh(3).
This is documented as
rcmdsh – return a stream to a remote command without superuser
And is implemented as a rather simple wrapper of getaddrinfo and exec.
This isn't something I'd imagine we'd add to libc now-a-days and is
currently broken by default (due to defaulting to _PATH_RSH)
I'm not sure there is much value in keeping this function around. I
did a rather naive search for uses of this function in ports and
couldn't find any. I'm preparing a more comprehensive patch for an
exp-run.
Does anyone have a reason to keep in libc? Any objection to removing
it? If no, is there anything special I need to do beyond just removing
the implementation and references?

Since I'm sending emails at 3:30am anyways, I'll point that generally
applies to rcmd(3) and related too.

I don't really understand the use-case for these functions on modern systems.

[Konstantin Belousov]

Now that the rcmds are removed from base, it opens a question about
what to do with rcmdsh(3).
This is documented as
rcmdsh ??? return a stream to a remote command without superuser
And is implemented as a rather simple wrapper of getaddrinfo and exec.
This isn't something I'd imagine we'd add to libc now-a-days and is
currently broken by default (due to defaulting to _PATH_RSH)
I'm not sure there is much value in keeping this function around. I
did a rather naive search for uses of this function in ports and
couldn't find any. I'm preparing a more comprehensive patch for an
exp-run.

There is a huge value in keeping ABI compatibility. The symbol must be kept.
You may remove default version for the symbol if you are so inclined.

Does anyone have a reason to keep in libc? Any objection to removing
it? If no, is there anything special I need to do beyond just removing
the implementation and references?
--
Eitan Adler
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-arch

[Eitan Adler]

Post by Konstantin Belousov

Now that the rcmds are removed from base, it opens a question about
what to do with rcmdsh(3).
This is documented as
rcmdsh ??? return a stream to a remote command without superuser
And is implemented as a rather simple wrapper of getaddrinfo and exec.
This isn't something I'd imagine we'd add to libc now-a-days and is
currently broken by default (due to defaulting to _PATH_RSH)
I'm not sure there is much value in keeping this function around. I
did a rather naive search for uses of this function in ports and
couldn't find any. I'm preparing a more comprehensive patch for an
exp-run.

There is a huge value in keeping ABI compatibility. The symbol must be kept.
You may remove default version for the symbol if you are so inclined.

I'm new at this. How does one do that?

[O'Connor, Daniel]

Post by Eitan Adler

Post by Konstantin Belousov

Now that the rcmds are removed from base, it opens a question about
what to do with rcmdsh(3).
This is documented as
rcmdsh ??? return a stream to a remote command without superuser
And is implemented as a rather simple wrapper of getaddrinfo and exec.
This isn't something I'd imagine we'd add to libc now-a-days and is
currently broken by default (due to defaulting to _PATH_RSH)
I'm not sure there is much value in keeping this function around. I
did a rather naive search for uses of this function in ports and
couldn't find any. I'm preparing a more comprehensive patch for an
exp-run.

There is a huge value in keeping ABI compatibility. The symbol must be kept.
You may remove default version for the symbol if you are so inclined.

I'm new at this. How does one do that?

You could just leave the call, I assume it will fail with an error if rsh isn't in the path.

If a user desperately needs it then they can install an rsh from ports (or something).

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum

[Eitan Adler]

Post by O'Connor, Daniel

Post by Eitan Adler

Post by Konstantin Belousov

Now that the rcmds are removed from base, it opens a question about
what to do with rcmdsh(3).
This is documented as
rcmdsh ??? return a stream to a remote command without superuser
And is implemented as a rather simple wrapper of getaddrinfo and exec.
This isn't something I'd imagine we'd add to libc now-a-days and is
currently broken by default (due to defaulting to _PATH_RSH)
I'm not sure there is much value in keeping this function around. I
did a rather naive search for uses of this function in ports and
couldn't find any. I'm preparing a more comprehensive patch for an
exp-run.

There is a huge value in keeping ABI compatibility. The symbol must be kept.
You may remove default version for the symbol if you are so inclined.

I'm new at this. How does one do that?

You could just leave the call, I assume it will fail with an error if rsh isn't in the path.

It will fail unconditionally since the call looks explicitly for
/bin/rsh. Is it wrong to change the implementation to use PATH?I have
not looked closely, but are there security implications to trusting
the environment?

[O'Connor, Daniel]

Post by Eitan Adler

Post by O'Connor, Daniel
You could just leave the call, I assume it will fail with an error if rsh isn't in the path.

It will fail unconditionally since the call looks explicitly for
/bin/rsh. Is it wrong to change the implementation to use PATH?I have
not looked closely, but are there security implications to trusting
the environment?

Hmm I see..
I think it could still be OK if the hypothetical rsh port had an option to add a symlink to /bin.

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum

[Cy Schubert]

In message <***@mail.gma
il.com>

Post by O'Connor, Daniel

Post by O'Connor, Daniel

Post by Eitan Adler

Post by Konstantin Belousov

Now that the rcmds are removed from base, it opens a question about
what to do with rcmdsh(3).
This is documented as
rcmdsh ??? return a stream to a remote command without superuser
And is implemented as a rather simple wrapper of getaddrinfo and exec.
This isn't something I'd imagine we'd add to libc now-a-days and is
currently broken by default (due to defaulting to _PATH_RSH)
I'm not sure there is much value in keeping this function around. I
did a rather naive search for uses of this function in ports and
couldn't find any. I'm preparing a more comprehensive patch for an
exp-run.

There is a huge value in keeping ABI compatibility. The symbol must be k

ept.

Post by O'Connor, Daniel

Post by Eitan Adler

Post by Konstantin Belousov
You may remove default version for the symbol if you are so inclined.

I'm new at this. How does one do that?

You could just leave the call, I assume it will fail with an error if rsh i

sn't in the path.
It will fail unconditionally since the call looks explicitly for
/bin/rsh. Is it wrong to change the implementation to use PATH?I have
not looked closely, but are there security implications to trusting
the environment?

If uid == 0, yes. To safely ensure that a setuid (root or otherwise)
program cannot be tricked into running some other application than
/bin/rsh, IMO the safest option might be to do what the kernel does
when executing init at boot. That is, select it from colon separated
list. We can default to /usr/local/bin/rsh with a src.conf option.

I don't believe rcmdsh() is POSIX or SPEC 1170, so it could default to
/usr/bin/ssh instead.

Personally, IMO, I think rcmdsh() is too much trouble for what it's
worth. It should be removed. Do we have an idea of how many
applications removing this function might impact? I'm willing to bet
very few.

[John Baldwin]

Post by Cy Schubert
il.com>

Post by O'Connor, Daniel

Post by O'Connor, Daniel

Post by Eitan Adler

Post by Konstantin Belousov

Now that the rcmds are removed from base, it opens a question about
what to do with rcmdsh(3).
This is documented as
rcmdsh ??? return a stream to a remote command without superuser
And is implemented as a rather simple wrapper of getaddrinfo and exec.
This isn't something I'd imagine we'd add to libc now-a-days and is
currently broken by default (due to defaulting to _PATH_RSH)
I'm not sure there is much value in keeping this function around. I
did a rather naive search for uses of this function in ports and
couldn't find any. I'm preparing a more comprehensive patch for an
exp-run.

There is a huge value in keeping ABI compatibility. The symbol must be k

ept.

Post by O'Connor, Daniel

Post by Eitan Adler

Post by Konstantin Belousov
You may remove default version for the symbol if you are so inclined.

I'm new at this. How does one do that?

You could just leave the call, I assume it will fail with an error if rsh i

sn't in the path.
It will fail unconditionally since the call looks explicitly for
/bin/rsh. Is it wrong to change the implementation to use PATH?I have
not looked closely, but are there security implications to trusting
the environment?

If uid == 0, yes. To safely ensure that a setuid (root or otherwise)
program cannot be tricked into running some other application than
/bin/rsh, IMO the safest option might be to do what the kernel does
when executing init at boot. That is, select it from colon separated
list. We can default to /usr/local/bin/rsh with a src.conf option.
I don't believe rcmdsh() is POSIX or SPEC 1170, so it could default to
/usr/bin/ssh instead.
Personally, IMO, I think rcmdsh() is too much trouble for what it's
worth. It should be removed. Do we have an idea of how many
applications removing this function might impact? I'm willing to bet
very few.

I think you could also just leave it as-is without changing the path and
require the user to explicitly create a suitable /usr/bin/rsh if they
require it for some reason. If you wanted to retire the symbol as suggested
by kib@ that would also be fine and would prevent new applications from
using it going forward (but you don't get to remove the source from libc).

[Eitan Adler]

I'm new at this. How does one do that?

Post by John Baldwin

Post by Cy Schubert
il.com>

Post by Eitan Adler

Post by Konstantin Belousov

Now that the rcmds are removed from base, it opens a question about
what to do with rcmdsh(3).
This is documented as
rcmdsh ??? return a stream to a remote command without superuser
And is implemented as a rather simple wrapper of getaddrinfo and

exec.

Post by Cy Schubert

Post by Eitan Adler

Post by Konstantin Belousov

This isn't something I'd imagine we'd add to libc now-a-days and is
currently broken by default (due to defaulting to _PATH_RSH)
I'm not sure there is much value in keeping this function around. I
did a rather naive search for uses of this function in ports and
couldn't find any. I'm preparing a more comprehensive patch for an
exp-run.

There is a huge value in keeping ABI compatibility. The symbol must

be k

Post by Cy Schubert

ept.

Post by Eitan Adler

Post by Konstantin Belousov
You may remove default version for the symbol if you are so inclined.

I'm new at this. How does one do that?

If you wanted to retire the symbol as suggested

using it going forward (but you don't get to remove the source from libc).

Sounds like a plan. I'm new at this. How does one do that?

[John Baldwin]

Post by John Baldwin

il.com <http://il.com>>

Post by Eitan Adler

Now that the rcmds are removed from base, it opens a question about
what to do with rcmdsh(3).
This is documented as
     rcmdsh ??? return a stream to a remote command without superuser
And is implemented as a rather simple wrapper of getaddrinfo and exec.
This isn't something I'd imagine we'd add to libc now-a-days and is
currently broken by default (due to defaulting to _PATH_RSH)
I'm not sure there is much value in keeping this function around. I
did a rather naive search for uses of this function in ports and
couldn't find any. I'm preparing a more comprehensive patch for an
exp-run.

There is a huge value in keeping ABI compatibility.  The symbol must be k

ept.

Post by Eitan Adler

You may remove default version for the symbol if you are so inclined.

I'm new at this. How does one do that?

 If you wanted to retire the symbol as suggested

using it going forward (but you don't get to remove the source from libc).
 Sounds like a plan. I'm new at this. How does one do that?

See https://reviews.freebsd.org/D12298 and the change to gets.c in
particular. You rename the function and add a __sym_compat(). You will
also want to update the manpage to note it has been removed and you need
to MFC the deprecation warning to older branches. Possibly the actual
removal needs to be deferred to 13.0 since we are fairly close to 12.0.
Also, we haven't had any real warnings. So, what I would do is the
following:

1) As a trial balloon, hack up a patch that just removes rcmd() and rcmdsh()
and any other related functions from the headers and request an exp-run
just to ensure ports don't blow up before investing a lot of work in the
"full" solution.

2) For 12.0 I would add __warn_references() warnings for rcmd() and rcmdsh()
(see gets.c for examples) as well as deprecation notices to the manual
pages. These changes can also be merged to stable branches.

3) After 12.0 branches, I would use the __sym_compat approach to preserve
the existing versioned symbols but remove the default version (this
also means removing the prototypes from headers). This patch will
probably also need an exp-run.