Re: master 588a0363d9a: Improve SELinux handling in Tramp

Re: master 588a0363d9a: Improve SELinux handling in Tramp

[Po Lu]

Michael Albinus <Michael.Albinus@gmx.de> writes:

> branch: master
> commit 588a0363d9a3ce6d678618ad545f7a8f9af27880
> Author: Michael Albinus <michael.albinus@gmx.de>
> Commit: Michael Albinus <michael.albinus@gmx.de>
>
>     Improve SELinux handling in Tramp
>     
>     * lisp/net/tramp-sh.el (tramp-stat-file-attributes-with-selinux)
>     (tramp-stat-directory-files-and-attributes-with-selinux): New defconst.
>     (tramp-do-file-attributes-with-ls)
>     (tramp-do-file-attributes-with-stat)
>     (tramp-do-directory-files-and-attributes-with-stat): Return also
>     SELinux context.
>     (tramp-remote-selinux-p, tramp-do-copy-or-rename-file): Adapt docstring.
>     
>     * lisp/net/tramp-sudoedit.el (tramp-sudoedit-do-copy-or-rename-file)
>     (tramp-sudoedit-remote-selinux-p): Adapt docstring.
>     (tramp-sudoedit-file-attributes-with-selinux): New defconst.
>     (tramp-sudoedit-handle-file-attributes): Use it.
>     
>     * lisp/net/tramp.el (tramp-convert-file-attributes):
>     Extract SELinux context.

If my understanding is correct, then with this change Tramp starts to
return SELinux context information from file-attributes.

Doesn't this mean Dired and similar should be adjusted to refrain from
trying to restore SELinux attributes when performing a copy from a
remote directory, given that different machines can have completely
incompatible SELinux configurations?

Re: master 588a0363d9a: Improve SELinux handling in Tramp

[Michael Albinus]

Po Lu <luangruo@yahoo.com> writes:

Hi,

> If my understanding is correct, then with this change Tramp starts to
> return SELinux context information from file-attributes.

No. There's no visible change outside Tramp, it still returns the
SELinux context with file-selinux-context calls only.

This patch is part of Tramp optimizations I'm working on the last
days. One observation from the traces is, that file-selinux-context
calls almost always happen shortly after file-attributes calls. So I've
adapted Tramp's file-attributes implementations to use also the "-Z"
option (for ls) or "%C" option (for stat) on the remote side. From the
result, the SELinux context is extracted and cached inside Tramp. It is
not returned with file-attributes.

When the next file-selinux-context call happens, Tramp checks first the
cache, before it sends the respective remote command. By this, often a
network roundtrip can be avoided.

> Doesn't this mean Dired and similar should be adjusted to refrain from
> trying to restore SELinux attributes when performing a copy from a
> remote directory, given that different machines can have completely
> incompatible SELinux configurations?

I don't believe so. Outside Tramp, nothing has changed.

Best regards, Michael.

Re: master 588a0363d9a: Improve SELinux handling in Tramp

[Po Lu]

Michael Albinus <michael.albinus@gmx.de> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
> Hi,
>
>> If my understanding is correct, then with this change Tramp starts to
>> return SELinux context information from file-attributes.
>
> No. There's no visible change outside Tramp, it still returns the
> SELinux context with file-selinux-context calls only.
>
> This patch is part of Tramp optimizations I'm working on the last
> days. One observation from the traces is, that file-selinux-context
> calls almost always happen shortly after file-attributes calls. So I've
> adapted Tramp's file-attributes implementations to use also the "-Z"
> option (for ls) or "%C" option (for stat) on the remote side. From the
> result, the SELinux context is extracted and cached inside Tramp. It is
> not returned with file-attributes.
>
> When the next file-selinux-context call happens, Tramp checks first the
> cache, before it sends the respective remote command. By this, often a
> network roundtrip can be avoided.
>
>> Doesn't this mean Dired and similar should be adjusted to refrain from
>> trying to restore SELinux attributes when performing a copy from a
>> remote directory, given that different machines can have completely
>> incompatible SELinux configurations?
>
> I don't believe so. Outside Tramp, nothing has changed.
>
> Best regards, Michael.

I see.  Thank you for explaining.