Hello all,
As http://www.kernel.org says, linux-3.[678] are already marked as EOL.
So aufs3.[678] are going to end too in very near future.
If you have a strong objection, please let me know.
J. R. Okajima
--
See ever
Hi,
Thanks for letting me know about this discussion.
Serge is correct. By allowing this flag, an un-privileged user can mount aufs
filesystem within the user namespace and the administrator needs to be aware of
this. However, I am not sure about the harm in letting an unprivileged user
mount t
sf...@users.sourceforge.net:
> Bhushan Jain:
> > Attached is a sample code that creates a user namespace and maps the un-pri=
> > vileged user to root within the namespace.=0A=
> > The user namespace can be used for sandboxing. Having aufs support within t=
> > he user namespace can help create a
Hello Andy,
Andy Whitcroft:
> The loop.h header has moved private within the drivers/block subsystem.
> For now just bodge this by switching to a relative path.
Yes, this is unplesant issue for aufs.
But I don't think this approach is good. For instance,
- a user wants to rebuild aufs module.
-
The loop.h header has moved private within the drivers/block subsystem.
For now just bodge this by switching to a relative path.
Signed-off-by: Andy Whitcroft
---
ubuntu/aufs/loop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Found this while porting aufs3 to 3.11-rc1 in Ubunt
