openssh bugs - Oct 2018 - [Bug 2922] New: missing service_name in check_service_files_ownership function of ssh-host-config for cygwin

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

            Bug ID: 2922
           Summary: missing service_name in check_service_files_ownership
                    function of ssh-host-config for cygwin
           Product: Portable OpenSSH
           Version: 7.7p1
          Hardware: amd64
                OS: Cygwin on NT/2k/W7/W8/W10
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Miscellaneous
          Assignee: unassigned-bugs at mindrot.org
          Reporter: Christian.Lupien at USherbrooke.ca

Created attachment 3195
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3195&action=edit
patch to fix the hardcoded sshd service name

On windows 10 (1803), there is already a sshd service present,
therefore during the cygwin sshd setup, using ssh-host-config, it
requires using the -N option to use a different service name. For
example:
 ssh-host-config -N cygwin_sshd

However that fails because during the function:
  check_service_files_ownership
it still tries to use the old sshd service name which is hardcoded.

The following patch fixes the problem for me (I was using
OpenSSH_7.8p1, but the problem is still there today 2018-10-22 on the
master branch)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org,
                   |                            |vinschen at redhat.com

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Corinna, could you please take a look at this?

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

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

--- Comment #2 from Corinna Vinschen <vinschen at redhat.com> ---
Created attachment 3201
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3201&action=edit
follow up fix

Patch is fine, but on inspection I found a few comments
suffering the same problem.  Also fixed a typo.  Patch attached.

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

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
                 CC|                            |dtucker at dtucker.net
             Blocks|                            |2893
             Status|NEW                         |RESOLVED

--- Comment #3 from Darren Tucker <dtucker at dtucker.net> ---
Applied both to head, thanks.  Both changes will be in the next major
release.  I also cherry picked the servicename fix into the V_7_9
branch so if there a is p2 release it'll be in it (we typically don't
do those unless something critical comes up).


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2893
[Bug 2893] Tracking bug for 7.9 release
-- 
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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

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

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

Ahmed Sayeed <ahmedsayeed1982 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ahmedsayeed1982 at yahoo.com

--- Comment #5 from Ahmed Sayeed <ahmedsayeed1982 at yahoo.com> ---
This patch fixes a segfault seen when attaching to a process on
Solaris.
    The steps leading to the segfault are:
    http://www.compilatori.com/tech/xiaomi/
     - procfs_target::attach calls do_attach, at this point the
inferior's
       process slot in the target stack is empty. 
     - do_attach adds a thread with `add
http://www.acpirateradio.co.uk/tech/forest-fires/ _thread
(&the_procfs_target, ptid)`
     - in add_thread_silent, the passed target (&the_procfs_target) is
       passed to find_inferior_ptid
http://www.logoarts.co.uk/tech/drone-cameras/
     - find_inferior_ptid returns nullptr, as there is no inferior with
this
       ptid that has &the_procfs_target as its process target
http://www.slipstone.co.uk/tech/express-van/
     - the nullptr `inf` is passed to find_thread_ptid, which
dereferences
       it, causing a segfault
     - back in procfs_target::attach, after do_attach, we push the
http://embermanchester.uk/technology/telegram/ 
       the_procfs_target on the inferior's target stack, although we
never
       reach this because the segfault happens before.
http://connstr.net/tech/mars-surface/

    To fix this, I think we need to do the same as is done in 
    inf_ptrace_target::attach: push the target early and unpush it in
case
    the attach fails (and keep it if the attach succeeds).
http://joerg.li/tech/cars-comparison/

    Implement it by moving target_unpush_up to target.h, so it can be
    re-used here.  Make procfs_target::attach use it.  Note that just
like
    is mentioned http://www.jopspeech.com/tech/xiaomi-headset/ in
inf_ptrace_target::attach, we should push the target
    before calling target_pid_to_str, so that calling target_pid_to_str
ends
    up in procfs_target::pid_to_str.
http://www.wearelondonmade.com/tech/driving-assistant/

    Tested by trying to attach on a process on gcc211 on the gcc
compile
    farm.
    https://waytowhatsnext.com/health/vaccination-rates/
    gdb/ChangeLog:
This patch fixes a segfault seen when attaching to a process on
Solaris.
    The steps leading to the segfault are:
http://www.iu-bloomington.com/health/amoled-display/

     - procfs_target::attach calls do_attach, at this point the
inferior's
       process slot in the target stack is empty.
https://komiya-dental.com/health/telegram-account/
     - do_attach adds a thread with `add_thread (&the_procfs_target,
ptid)`
     - in add_thread_silent, the passed target (&the_procfs_target) is
       passed to find_inferior_ptid
http://www-look-4.com/services/usb-type-a/
     - find_inferior_ptid returns nullptr, as there is no inferior with
this
       ptid that has &the_procfs_target as its process target
     - the nullptr `inf` is passed to find_thread_ptid, which
dereferences
       it, causing a segfault
https://www.webb-dev.co.uk/property/house-sales-in-2020/
     - back in procfs_target::attach, after do_attach, we push the
       the_procfs_target on the inferior's target stack, although we
never
       reach this because the segfault happens before.

    To fix this, I think we need to do the same as is done in
    inf_ptrace_target::attach: push the target early and unpush it in
case
    the attach fails (and keep it if the attach succeeds).

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