Re: sed suggestion: selinux context based on symlink when using -i

[Jakub Martisko]

Hi, any updates?

On 28.11.2017 14:06, Jakub Martisko wrote:
> As promised, here is the patch. Comments/suggestions are
> welcomed.
> 
> Jakub
> 
> On 23.11.2017 14:26, Jakub Martisko wrote:
>> Hi and thank you for your reply, I'll try to provide a
>> complete patch as soon as I identify the correct entry for
>> the NEWS file.
>> As for the --follow-symlinks option - unpatched version
>> fails at the first grep in the attached test script (and
>> succeeds at the second one), while the patched version
>> passes both. I hope this is the expected/wanted behaviour.
>>
>> Thanks.
>> Jakub
>>
>>
>>
>>
>> On 22.11.2017 17:26, Jim Meyering wrote:
>>> On Wed, Nov 22, 2017 at 3:23 AM, Jakub Martisko <address@hidden> wrote:
>>>> On 11.1.2017 09:19, Jakub Martisko wrote:
>>>>> First of all, congratulations and thanks for the GNU sed 4.3
>>>>> release.
>>>>>
>>>>> Now to the main topic. There was a suggestion (see the
>>>>> discussion in [1]) to change how the sed handles the selinux
>>>>> context when working with symlinked files when using the -i
>>>>> option. It was suggested that the context should be based on
>>>>> the link instead of the target file itself. Patch that
>>>>> changes this behavior was also proposed and is attached to
>>>>> this message. Any thoughts about this suggestion?
>>>>>
>>>>> Regards,
>>>>> Jakub
>>>>>
>>>>> P.S. I hope that his is a correct list where to post this.
>>>>>
>>>>>
>>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1401442
>>>
>>> Thank you for reporting that and for taking the time to prepare a patch.
>>> Are you interested in making it a complete patch?
>>> Since it is a bug fix, the patch should add an entry in the NEWS file.
>>> Each bug fix also deserves regression tests: tests that fail before
>>> and succeed after the patch is applied.
>>> Will this patch have to take into account whether the
>>> --follow-symlinks command-line option is specified? (haven't looked
>>> yet)
>>> If so, then there should be in-place tests that exercise this, both
>>> with and without that option.
>>>
>>> Finally, for each bug fix, we try hard to identify the released
>>> version in which the bug was introduced (mention that in NEWS), and
>>> the actual commit (mention that in the commit log for the patch).
>>>
>>> Thanks again for the report and patch.
>>> No obligation on your part to do any of the above.
>>> Just outlining what's required, in case you're inclined.
>>> If you don't do it, someone else will.
>>>