Date: Mon, 02 Jul 2018 20:30:38 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Eitan Adler <lists@eitanadler.com> Cc: "O'Connor, Daniel" <darius@dons.net.au>, Konstantin Belousov <kostikbel@gmail.com>, "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: What to do about rcmdsh(3) ? Message-ID: <201807030330.w633Uchd087857@slippy.cwsent.com> In-Reply-To: Message from Eitan Adler <lists@eitanadler.com> of "Sat, 30 Jun 2018 20:42:24 -0700." <CAF6rxgmJZyivZtQDKnUa12DJ5PqWVp40wOQg5Wt8zJWeuUUJYg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201807030330.w633Uchd087857>