Re: restorecon and symbolic links

[Martin Orr <martin@martinorr.name>]

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@tycho.nsa.gov>
> 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@tycho.nsa.gov>
> 
> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.