Date: Tue, 3 Jul 2018 09:03:36 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Cy Schubert <Cy.Schubert@cschubert.com>, Eitan Adler <lists@eitanadler.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, "freebsd-arch@freebsd.org" <arch@freebsd.org>, "O'Connor, Daniel" <darius@dons.net.au> Subject: Re: What to do about rcmdsh(3) ? Message-ID: <a16098ab-45a8-7e52-d692-76ec723337b3@FreeBSD.org> In-Reply-To: <201807030330.w633Uchd087857@slippy.cwsent.com> References: <201807030330.w633Uchd087857@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/2/18 8:30 PM, Cy Schubert wrote: > In message <CAF6rxgmJZyivZtQDKnUa12DJ5PqWVp40wOQg5Wt8zJWeuUUJYg@mail.gma > il.com> > , Eitan Adler writes: >> On 26 June 2018 at 23:45, O'Connor, Daniel <darius@dons.net.au> wrote: >>> >>> >>>> On 27 Jun 2018, at 13:01, Eitan Adler <lists@eitanadler.com> wrote: >>>> >>>> On 24 June 2018 at 05:14, Konstantin Belousov <kostikbel@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a16098ab-45a8-7e52-d692-76ec723337b3>