Hi, On Tuesday 24 November 2015, Radek Podgorny wrote: > hello everyone! > > i'd like to sincerely ask you to include a fix for ssh-copy-id bug > i'll be linking below. it's a trivial fix which resolves > https://bugzilla.mindrot.org/show_bug.cgi?id=2206 and eases life of > many. it's been field-tested by redhat devs and users so i see no > problem in incorporating it. > > http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.8p1-fix >-ss h-copy-id-on-non-sh-shell.patch >> - umask 077 ; >> + exec sh -c 'umask 077; mkdir -p .ssh && cat >> .ssh/authorized_keys || exit 1; if type restorecon >/dev/null 2>&1; then restorecon -F .ssh .ssh/authorized_keys; fi'" \ >> - mkdir -p .ssh && cat >> .ssh/authorized_keys || exit 1 ; >> - if type restorecon >/dev/null 2>&1 ; then restorecon -F .ssh .ssh/authorized_keys ; fi" \ Does "exec sh -c ..." really make sense in general? People who are using non-posix login shells where not even "2>&1" or "&&" works are probably good candidates who would also link /bin/sh to point to a non-posix shell. Personally I think it's hard enough to write POSIX compatible shell scripts and I wouldn't start to add such hacks for fish and tcsh. Next week somebody may complain that his "shell" does not support "exec ...". cu, Rudi _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
