On 31/08/09 13:17, Stephen Smalley wrote: > On Sat, 2009-08-29 at 18:19 -0500, Manoj Srivastava wrote: >> On Sat, Aug 29 2009, Martin Orr wrote: >> >>> With policycoreutils 2.0.71, "restorecon /dev/stdin" fails if stdin is a pipe: >>> martin@caligula:~$ echo hi | sudo restorecon /dev/stdin >>> realpath(/dev/stdin) failed No such file or directory >>> >>> Why would you want to do this? >>> The Debian udev init script does >>> ln -s /proc/self/fd/0 /dev/stdin >>> restorecon /dev/stdin >>> I am not sure why stdin is a pipe here but it is some consequence of the >>> boot process. >>> >>> The intention here (and what happened with policycoreutils 2.0.69) is to >>> relabel the symbolic link. But the recent realpath patch changed this, and >>> I don't think there is a way now to ask restorecon to relabel an individual >>> symlink. >> There are consequences to this change not mentioned above: when >> booting with policycoreutils 2.0.71 /dev/pts (and several other device >> nodes) are not created which causes all sorts of trouble. >> >> This is a consequence of the realpath changes in restorecon, because >> when /lib/udev/create_static_nodes does >> ln -s /proc/self/fd/0 /dev/stdin >> restorecon /dev/stdin >> it now fails with the error >> realpath(/dev/stdin) failed No such file or directory >> This causes create_static_nodes to exit (due to set -e) before creating >> /dev/pts. >> >> I am planning on reverting the removal of special treatment of >> symlinks from the debian unstable version until this is resolved. > > The particular commit was: > > commit 37c5c30998b73d9c6efe53fd0534256463991c5e > Author: Stephen Smalley <sds@xxxxxxxxxxxxx> > Date: Mon Aug 3 09:34:52 2009 -0400 > > setfiles: only call realpath() on user-supplied pathnames > > Change setfiles/restorecon to only call realpath() on the user-supplied > pathnames prior to invoking fts_open(). This ensures that commands such > as restorecon -R /etc/init.d and (cd /etc && restorecon shadow gshadow) > will work as expected while avoiding the overhead of calling realpath() > on each file during a file tree walk. > > Since we are now only acting on user-supplied pathnames, drop the > special case handling of symlinks (when a user invokes restorecon > -R /etc/init.d he truly wants it to descend /etc/rc.d/init.d). We can > also defer allocation of the pathname buffer to libc by passing NULL > (freeing on the out path) and we can drop the redundant exclude() check > as it will now get handled on the normal path. > > Signed-off-by: Stephen Smalley <sds@xxxxxxxxxxxxx> > > What behavior would you like instead? I'd still like to have restorecon > -R /etc/init.d to do what the user expects, which isn't just relabel the > symlink. True, but I would expect restorecon -R /etc/init.d to relabel the symlink as well as descend into the directory. On the whole I would expect it not to relabel the target of the symlink itself but I don't have a strong opinion on that, as long as it doesn't fail if the symlink is broken. -- Martin Orr -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
