kernel-packages team mailing list archive

[Wojciech Kocjan <wojciech.kocjan@xxxxxxxxx>]

Public bug reported:

I have found aufs not supporting application performing the following
steps in order to download a .so embedded in the binary. The code does:

1/ open() a temp file, write() contents of .so to the file and close() it
2/ perform dlopen() on the file and dlsym() to find one or more symbols
3/ perform unlink() to remove it, while keeping handle from dlopen() open - NOT calling dlclose() - since the code calls APIs from the temp .so
4/ this library works, but subsequent calls fail

The issue applies to Ubuntu 12.04, 13.04 and 13.10 from the ones that I
have checked. I can provide the additional Linux kernel details,
however, as it is not specific to Linux version, but issue is not
applying one of the patches from aufs and quite a long investigation has
already been made, I hope it is not needed.

After checking with aufs author, it seems the problem is caused by
Ubuntu build process not applying aufs3-proc_map.patch:

"Ubuntu doesn't apply aufs3-proc_map.patch, but I always apply it (and
enable CONFIG_AUFS_PROC_MAP).
I have to confess that I didn't test aufs _without_
aufs3-proc_map.patch. With the patch, aufs works correctly. That is the
reason I could not reproduce the problem on my test machine.
Now your test program succeeds on my ubuntu machine with appllying
aufs3-proc_map.patch.

The purpose of aufs3-proc_map.patch is to change only the shown path in
/proc/PID/maps. So this is a problem of aufs definitly. I will try
fixing this bug as soon as possible, but I am going to be busy and it
may take some time. So the first and simplest solution for you is to ask
ubuntu people to apply aufs3-proc_map.patch, if they don't have any
objection."

Would it be possible to apply the patch in Ubuntu? Since this is the
most common way to build it and this is what the aufs author does, it
should be safest to also apply it. Without it it seems that lifetime of
file object is not correct and it causes inode numbers to be reused,
like in this case.

Original bug report against aufs: 
http://sourceforge.net/p/aufs/bugs/19/ 

Discussion related to the bug report: 
http://sourceforge.net/mailarchive/forum.php?thread_name=11413.1382101611%40jrobl&forum_name=aufs-users

The bug report also includes sample code to reproduce the problem - the
/tmp has to be mounted as aufs to reproduce it.

** Affects: linux (Ubuntu)
     Importance: Undecided
         Status: Incomplete

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1243591

Title:
  aufs shipped with Ubuntu does not properly handle aufs does not
  properly support dlopen() + unlink()

Status in “linux” package in Ubuntu:
  Incomplete

Bug description:
  I have found aufs not supporting application performing the following
  steps in order to download a .so embedded in the binary. The code
  does:

  1/ open() a temp file, write() contents of .so to the file and close() it
  2/ perform dlopen() on the file and dlsym() to find one or more symbols
  3/ perform unlink() to remove it, while keeping handle from dlopen() open - NOT calling dlclose() - since the code calls APIs from the temp .so
  4/ this library works, but subsequent calls fail

  The issue applies to Ubuntu 12.04, 13.04 and 13.10 from the ones that
  I have checked. I can provide the additional Linux kernel details,
  however, as it is not specific to Linux version, but issue is not
  applying one of the patches from aufs and quite a long investigation
  has already been made, I hope it is not needed.

  After checking with aufs author, it seems the problem is caused by
  Ubuntu build process not applying aufs3-proc_map.patch:

  "Ubuntu doesn't apply aufs3-proc_map.patch, but I always apply it (and
  enable CONFIG_AUFS_PROC_MAP).
  I have to confess that I didn't test aufs _without_
  aufs3-proc_map.patch. With the patch, aufs works correctly. That is the
  reason I could not reproduce the problem on my test machine.
  Now your test program succeeds on my ubuntu machine with appllying
  aufs3-proc_map.patch.

  The purpose of aufs3-proc_map.patch is to change only the shown path in
  /proc/PID/maps. So this is a problem of aufs definitly. I will try
  fixing this bug as soon as possible, but I am going to be busy and it
  may take some time. So the first and simplest solution for you is to ask
  ubuntu people to apply aufs3-proc_map.patch, if they don't have any
  objection."

  Would it be possible to apply the patch in Ubuntu? Since this is the
  most common way to build it and this is what the aufs author does, it
  should be safest to also apply it. Without it it seems that lifetime
  of file object is not correct and it causes inode numbers to be
  reused, like in this case.

  Original bug report against aufs: 
  http://sourceforge.net/p/aufs/bugs/19/ 

  Discussion related to the bug report: 
  http://sourceforge.net/mailarchive/forum.php?thread_name=11413.1382101611%40jrobl&forum_name=aufs-users

  The bug report also includes sample code to reproduce the problem -
  the /tmp has to be mounted as aufs to reproduce it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1243591/+subscriptions