Le 20/08/2014 18:25, Richard Guy Briggs a écrit :
On 14/08/19, Eric W. Biederman wrote:
Richard Guy Briggs <rgb@xxxxxxxxxx> 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
http://thread.gmane.org/gmane.linux.network/315933/focus=321753).
This serial number solution may be reused for this.
We really need to find a way to solve this.
Regards,
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html