[arch-dev-public] [signoff] openssh 5.4p1-2
So, it's me again. This time we should have an openssh package which fixes both of these bugs: http://bugs.archlinux.org/task/18611 http://bugs.archlinux.org/task/17138 Please sign-off, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am Mittwoch, 10. März 2010 16:36:15 schrieb Pierre Schmitz:
So, it's me again. This time we should have an openssh package which fixes both of these bugs: http://bugs.archlinux.org/task/18611 http://bugs.archlinux.org/task/17138
Please sign-off,
Pierre
This is really not my day and I already regret touching this package. :-) The problem with using readlink /proc/$pid/exe is that during an update of a running sshd that link will point nowhere. As a result the restart will fail. What do you think about using /proc/$pid/cmdline instead? -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am Mittwoch, 10. März 2010 17:08:45 schrieb Pierre Schmitz:
Am Mittwoch, 10. März 2010 16:36:15 schrieb Pierre Schmitz:
So, it's me again. This time we should have an openssh package which fixes both of these bugs: http://bugs.archlinux.org/task/18611 http://bugs.archlinux.org/task/17138
Please sign-off,
Pierre
This is really not my day and I already regret touching this package. :-) The problem with using readlink /proc/$pid/exe is that during an update of a running sshd that link will point nowhere. As a result the restart will fail.
What do you think about using /proc/$pid/cmdline instead?
Just found out that this wont work with ssh_args set in /ec/conf.d/sshd. My last resort would be stripping that possible "(deleted)" fro mthe readlink output. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Wed, Mar 10, 2010 at 10:16 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Mittwoch, 10. März 2010 17:08:45 schrieb Pierre Schmitz:
Am Mittwoch, 10. März 2010 16:36:15 schrieb Pierre Schmitz:
So, it's me again. This time we should have an openssh package which fixes both of these bugs: http://bugs.archlinux.org/task/18611 http://bugs.archlinux.org/task/17138
Please sign-off,
Pierre
This is really not my day and I already regret touching this package. :-) The problem with using readlink /proc/$pid/exe is that during an update of a running sshd that link will point nowhere. As a result the restart will fail.
What do you think about using /proc/$pid/cmdline instead?
Just found out that this wont work with ssh_args set in /ec/conf.d/sshd. My last resort would be stripping that possible "(deleted)" fro mthe readlink output.
So what's the actual issue with pidof? "pidof -o %PPID" is supposed to return JUST the parent process's pid, not the children. Is it returning the wrong pid? Hrm, checking this on an arbitrary machine at work: $ ps ax | grep sshd 5436 ? Ss 0:16 /usr/sbin/sshd 32128 ? Ss 0:00 sshd: agriffin [priv] 32130 ? S 0:00 sshd: agriffin@pts/3 32435 pts/3 R+ 0:00 grep sshd $ pidof -o %PPID /usr/bin/sshd 32130 32128 So... why aren't we getting the actual parent pid here?
Am 10.03.2010 17:23, schrieb Aaron Griffin:
So what's the actual issue with pidof? "pidof -o %PPID" is supposed to return JUST the parent process's pid, not the children. Is it returning the wrong pid?
<quote> -o Tells pidof to omit processes with that process id. The special pid %PPID can be used to name the parent process of the pidof program, in other words the calling shell or shell script. </quote> There is no way we can do this with pidof.
So, what should we actually do about this? It seems there is no simple resolution to fix both bugs. My suggestion would be to revert the rc.d script changes and see if we could come up with a better approach in the future. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 13/03/10 03:23, Pierre Schmitz wrote:
So, what should we actually do about this? It seems there is no simple resolution to fix both bugs. My suggestion would be to revert the rc.d script changes and see if we could come up with a better approach in the future.
Just revert it and (re)open a bug report with all the details so it does not get lost.
Am 12.03.2010 23:17, schrieb Allan McRae:
On 13/03/10 03:23, Pierre Schmitz wrote:
So, what should we actually do about this? It seems there is no simple resolution to fix both bugs. My suggestion would be to revert the rc.d script changes and see if we could come up with a better approach in the future.
Just revert it and (re)open a bug report with all the details so it does not get lost.
I still don't see what's wrong about the solution I provided.
Am Freitag, 12. März 2010 23:42:53 schrieb Thomas Bächler:
Just revert it and (re)open a bug report with all the details so it does not get lost.
I still don't see what's wrong about the solution I provided.
I am not sure which solution you meant. (there is none in this thread) -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am 13.03.2010 00:18, schrieb Pierre Schmitz:
Am Freitag, 12. März 2010 23:42:53 schrieb Thomas Bächler:
Just revert it and (re)open a bug report with all the details so it does not get lost.
I still don't see what's wrong about the solution I provided.
I am not sure which solution you meant. (there is none in this thread)
Am Samstag, 13. März 2010 11:32:40 schrieb Thomas Bächler:
Am 13.03.2010 00:18, schrieb Pierre Schmitz:
Am Freitag, 12. März 2010 23:42:53 schrieb Thomas Bächler:
Just revert it and (re)open a bug report with all the details so it does not get lost.
I still don't see what's wrong about the solution I provided.
I am not sure which solution you meant. (there is none in this thread)
$(readlink /proc/$PID/exe) will return "/usr/sbin/sshd (deleted)" if you update a running sshd. A sshd stop will fail then. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am 10.03.2010 17:16, schrieb Pierre Schmitz:
This is really not my day and I already regret touching this package. :-) The problem with using readlink /proc/$pid/exe is that during an update of a running sshd that link will point nowhere. As a result the restart will fail.
What do you think about using /proc/$pid/cmdline instead?
Just found out that this wont work with ssh_args set in /ec/conf.d/sshd. My last resort would be stripping that possible "(deleted)" fro mthe readlink output.
The sshd symlink is not actually a symlink, it is something weird. It will always seem to point to the right "path" as far as I know, even when the binary is changed or deleted.
participants (4)
-
Aaron Griffin
-
Allan McRae
-
Pierre Schmitz
-
Thomas Bächler