What to do about rcmdsh(3) ?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

What to do about rcmdsh(3) ?

Eitan Adler-4
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?

--
Eitan Adler
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What to do about rcmdsh(3) ?

Eitan Adler-4
On 24 June 2018 at 03:32, Eitan Adler <[hidden email]> wrote:

> 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.


--
Eitan Adler
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What to do about rcmdsh(3) ?

Konstantin Belousov
In reply to this post by Eitan Adler-4
On Sun, Jun 24, 2018 at 03:32:13AM -0700, Eitan Adler wrote:

> 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
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What to do about rcmdsh(3) ?

Eitan Adler-4
On 24 June 2018 at 05:14, Konstantin Belousov <[hidden email]> wrote:

> On Sun, Jun 24, 2018 at 03:32:13AM -0700, Eitan Adler wrote:
>> 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?


--
Eitan Adler
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What to do about rcmdsh(3) ?

O'Connor, Daniel-2


> On 27 Jun 2018, at 13:01, Eitan Adler <[hidden email]> wrote:
>
> On 24 June 2018 at 05:14, Konstantin Belousov <[hidden email]> wrote:
>> On Sun, Jun 24, 2018 at 03:32:13AM -0700, Eitan Adler wrote:
>>> 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


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What to do about rcmdsh(3) ?

Eitan Adler-4
On 26 June 2018 at 23:45, O'Connor, Daniel <[hidden email]> wrote:

>
>
>> On 27 Jun 2018, at 13:01, Eitan Adler <[hidden email]> wrote:
>>
>> On 24 June 2018 at 05:14, Konstantin Belousov <[hidden email]> wrote:
>>> On Sun, Jun 24, 2018 at 03:32:13AM -0700, Eitan Adler wrote:
>>>> 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?




--
Eitan Adler
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What to do about rcmdsh(3) ?

O'Connor, Daniel-2


> On 1 Jul 2018, at 13:12, Eitan Adler <[hidden email]> wrote:
>> 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


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What to do about rcmdsh(3) ?

Cy Schubert-4
In reply to this post by Eitan Adler-4
In message <[hidden email]
il.com>
, Eitan Adler writes:

> On 26 June 2018 at 23:45, O'Connor, Daniel <[hidden email]> wrote:
> >
> >
> >> On 27 Jun 2018, at 13:01, Eitan Adler <[hidden email]> wrote:
> >>
> >> On 24 June 2018 at 05:14, Konstantin Belousov <[hidden email]> wrote:
> >>> On Sun, Jun 24, 2018 at 03:32:13AM -0700, Eitan Adler wrote:
> >>>> 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.
> >>> 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.


--
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  http://www.FreeBSD.org

        The need of the many outweighs the greed of the few.


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What to do about rcmdsh(3) ?

John Baldwin
On 7/2/18 8:30 PM, Cy Schubert wrote:

> In message <[hidden email]
> il.com>
> , Eitan Adler writes:
>> On 26 June 2018 at 23:45, O'Connor, Daniel <[hidden email]> wrote:
>>>
>>>
>>>> On 27 Jun 2018, at 13:01, Eitan Adler <[hidden email]> wrote:
>>>>
>>>> On 24 June 2018 at 05:14, Konstantin Belousov <[hidden email]> wrote:
>>>>> On Sun, Jun 24, 2018 at 03:32:13AM -0700, Eitan Adler wrote:
>>>>>> 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.
>>>>> 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).

--
John Baldwin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What to do about rcmdsh(3) ?

Eitan Adler-4
I'm new at this. How does one do that?

On Tuesday, 3 July 2018, John Baldwin <[hidden email]> wrote:

> On 7/2/18 8:30 PM, Cy Schubert wrote:
> > In message <[hidden email]
> > il.com>
> > , Eitan Adler writes:
> >> On 26 June 2018 at 23:45, O'Connor, Daniel <[hidden email]> wrote:
> >>>
> >>>
> >>>> On 27 Jun 2018, at 13:01, Eitan Adler <[hidden email]> wrote:
> >>>>
> >>>> On 24 June 2018 at 05:14, Konstantin Belousov <[hidden email]>
> wrote:
> >>>>> On Sun, Jun 24, 2018 at 03:32:13AM -0700, Eitan Adler wrote:
> >>>>>> 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.
> >>>>> 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
> 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).


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


--
Sent from my Turing Machine
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: What to do about rcmdsh(3) ?

John Baldwin
On 7/3/18 9:43 AM, Eitan Adler wrote:

> On Tuesday, 3 July 2018, John Baldwin <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 7/2/18 8:30 PM, Cy Schubert wrote:
>     > In message <[hidden email]
>     > il.com <http://il.com>>
>     > , Eitan Adler writes:
>     >> On 26 June 2018 at 23:45, O'Connor, Daniel <[hidden email] <mailto:[hidden email]>> wrote:
>     >>>
>     >>>
>     >>>> On 27 Jun 2018, at 13:01, Eitan Adler <[hidden email] <mailto:[hidden email]>> wrote:
>     >>>>
>     >>>> On 24 June 2018 at 05:14, Konstantin Belousov <[hidden email] <mailto:[hidden email]>> wrote:
>     >>>>> On Sun, Jun 24, 2018 at 03:32:13AM -0700, Eitan Adler wrote:
>     >>>>>> 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.
>     >>>>> 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
>     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).
>
>
>  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.

--
John Baldwin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"