A recent use-case on Slackware made me re-visit CVE-2005-4890 in the context of "su -c". Particularly, shadow's implementation as of shadow 4.1.5. During the discussions of this CVE (see footer links), it was pointed out shadow's fix is partial given interactive su remains vulnerable to tty-hijacking. It was also mentioned this vector is less worrisome given use cases for interactive su are primarily privilege escalation. The CVE was always a bit controversial with many believing using su and sudo to drop privileges is unsafe and more an administration issue than a design flaw. All that said, at the very least would it be reasonable to apply the same threat-assessment criterion to the crippling of "su -c" and not drop the controlling tty for the case when the callee is root? Slackware doesn't use PAM so the fix in shadow relies on a TIOCNOTTY ioctl() request and not a setsid() call. One result of this change is summarized in the table below: shadow 4.1.4.3 4.1.5.1 4.1.5.1+patch* 1. As unpriv user user1: xterm -e su -c $COMM SUCCESS FAIL SUCCESS xterm -e su user2 -c $COMM SUCCESS FAIL FAIL 2. As root: xterm -e su user1 -c $COMM SUCCESS FAIL FAIL ----- * See attached Cheers. --mancha