On 14/08/19, Eric W. Biederman wrote:
> Richard Guy Briggs <rgb(a)redhat.com> writes:
>
>> On 14/05/20, Richard Guy Briggs wrote:
>>> On 14/05/20, Eric Paris wrote:
>>>> On Tue, 2014-05-20 at 09:12 -0400, Richard Guy Briggs wrote:
>>>>> The purpose is to track namespaces in use by logged processes from
the
>>>>> perspective of init_*_ns.
>>
>> (Including the Linux API list due to the additions to /proc/<pid>/ns/.
>> Please see
http://www.kernelhub.org/?p=2&msg=477668 and in particular
>>
http://www.kernelhub.org/?msg=477678&p=2 )
>
> Sigh if you have to use something like this use the proc inode
> number. It is the same thing.
>
> I hate to claim it is unique absent of the proc superblock but it is and
> will be for the forseable future.
>
> It would be better to include the block device number that appears in
> proc of 3h of the primary mount of to qualify the number. But it is not
> particularly important. Coming up with an additional unique number that
> needs to be maintained seems stronlgy silly.
I am reading a contradiction here:
https://www.redhat.com/archives/linux-audit/2013-March/msg00032.html
and this posting went completely ignored:
https://www.redhat.com/archives/linux-audit/2014-January/msg00180.html
And then there was this patchset and thread where there was some good
discussion to clarify the use case:
https://lkml.org/lkml/2014/4/22/662
Then V2:
https://lkml.org/lkml/2014/5/9/637
Then V3 3 months ago:
https://www.redhat.com/archives/linux-audit/2014-May/msg00071.html
I'm about to post another version of the patchset addressing Eric Paris'
concerns about record types, field naming...
I also try to find a solution to
identify netns in userland to solve
some network problems (see
).
This serial number solution may be reused for this.
We really need to find a way to solve this.
Regards,
Nicolas