- actual operation, reproducible one is better
- mailto: aufs-users at lists.sourceforge.net
--
Last but not lease, as you surely know, aufs3.4 has been unsuppo
20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I will prepare another environment and try newer gcc. This may need
some time. Ple
mplicit-fallthrough=]
Thanx for the patch.
Before apply this patch, would you tell me the version of your compiler?
J. R. Okajima
eep the manual not describing wsum option, but I gladly and
thankfully apply your patch.
J. R. Okajima
"J. R. Okajima":
> I will prepare another environment and try newer gcc. This may need
> some time. Please be patient.
Now I am trying with gcc-v8.3 (Debian 8.3.0-6), and I can see the
warning.
> @@ -1499,8 +1499,10 @@ static int au_opt_br(struct super_block *sb, st
the mainline.
J. R. Okajima
- aufs4-linux.git
aufs: bugfix, opts: Fix missing break statement
aufs: opts: Fix missing fallthrough
- aufs5-linux.git
ditto
- aufs4-standalone.git
ditto
- aufs5-standalone.git
ditto
- aufs-util.git
nothing
onto linux-v4.19.63, and it broke aufs4-mmap.patch,
reported by Yoann Ricordel.
- new branch aufs5.2.5+
similar to aufs4.19.63+ (above).
aufs5.x-rcN branch in this release is for linux-v5.3-rc6.
There is no change in aufs code.
J. R. Okajima
The aufs-util code essentially won't
change. Just the version checking will change.
J. R. Okajima
o news
- linux-v5.3 comes out, so aufs5.3 too.
it makes the life of aufs4.1[4-8] to the end.
my new development base version is now linux-v4.19.
The source code of aufs5.3 doesn't change from previous aufs5.x-rcN.
J. R. Okajima
re
mounted on the standard path such as "/lib". If they are mounted under
/au_branches or something, they never overlap with the existing AA
profiles, aren't they? If there are any other problem, please let me
know.
J. R. Okajima
-v5.2.
--> I cannot enable acl on NFS, still investigating.
J. R. Okajima
hardwares. But choosing the little old hardwares
is not so easy in my town. I am picking up the cheaper hardwares from
the shop and checking the support status now.
J. R. Okajima
intrigeri:
> J. R. Okajima:
:::
> > Does your AppArmor setting allow reading "/etc/ld.so.cache" and
> > "/usr/lib/x86_64-linux-gnu/*.so*", but deny for "/live/image/..."?
>
> Using AppArmor with aufs (or overlayfs by the way) is a bit tri
ufs development, especially compile and tests are
done this year.
J. R. Okajima
James B:
> > Is it acceptable for you?
>
> Yes, this would work.
Ok, here is the fixed proc_mounts.patch for aufs5.3.
If everything goes well, I will release it on next Monday.
J. R. Okajima
proc_mounts.patch.bz2
Description: BZip2 compressed data
u have it)
- behaviour which you think to be incorrect
- actual operation, reproducible one is better
- mailto: aufs-users at lists.sourceforge.net
And, if you can, try "strace -f -o /tmp/s man brabra" and identify the
systemcall who retruned t
7-2
* stable-sec: 4.19.67-2+deb10u1
> Unfortunately, I could not find the responsible system call.
That is sad.
We have to track down the behaviour of man(1) more deeply, because no
suspicious systemcall was found. What made man(1) causes an error, any
library funcion?
J. R. Okajima
dev/console
fi
> I have attached the output of strace. Somehow I suspect the ioctl in
> line 2510 to be the problem, but I wonder how aufs can have an effect on
> that TTY operation.
I don't think it is related.
J. R. Okajima
y speaking, even after 1470 EACCES, the searching journey
continues, not ends. The story doesn't change though.
J. R. Okajima
n is 4.19.17+-20190211
- you should use aufs4.19.63+ series whose mmap.patch is different from
aufs4.19.17+'s.
But if this is the real cause, then you should meet the build error
before this problem. I cannot see what is going on.
J. R. Okajima
object in kernel. Once it gets crazy, aufs internal function
au_finfo_fin() will produce the BUG line, just as your syslog.
So I'd say, this mm/nommu.c in debian kernel has a bug, and it must be
the first thing to solve your problem.
J. R. Okajima
> - aufs4-mmap.patch is applied in-correctly,
> or in-correct version is applied,
> or bad aufs version which contained a in-correct version is used.
I've found an old mail about aufs4-mmap.patch.
J. R. Okajima
From:
To: a
J. R. Okajima
Hi,
Tomas M:
> I would suggest to solve this problem this way:
> - in aufs, do not change anything
> - in aufs documentation, provide some warning that apparmor must be
> configured properly to allow access to files on all branches.
Thanx for your suggestion.
I will take this
aufs/parameters/debug".
Additionally "echo 8 > /proc/sys/kernel/printk" will be necessary too.
And run your man command, aufs will produce many debug msgs to your
kernel log file. Let's investigate the log.
J. R. Okajima
in aufs release may help you I hope.
Such huge log file must be heavy for you. Of course me too.
It is better to set 1 to sys/module/aufs/parameters/debug just before
you run man(1), and just after man, set 0 in order to stop the debug
log.
J. R. Okajima
's.
>
> Unfortunately, man also does not work correctly with aufs4.19.63+. :-(
Do you mean that you applied aufs4-mmap.patch from aufs4.19.63+ and
rebuild your kernel itself not only aufs module?
(but I am not sure whether aufs4-mmap.patch is the cause of the problem)
J. R. Okajima
* pid 4091 troff fails because it cannot find libstdc++.so.6.
So the first action should be making these libraries to be loadable.
There are several things to do it, $LD_LIBRARY_PATH, /lib/ld-linux.so.*,
/etc/ld.so.*, and brabra.
But I am still afraid that "mount move" is important.
J. R. Okajima
Ouch!
My test machine is finally dead. It is Core2-duo, 4GB, 512GB HDD, 10
year old...
I have to get a new pc and replace it. Until then, all my development
stops. Hopefully it will be within a week or two.
J. R. Okajima
read(2) will return 999. It seems hard for
seq_file (linux kenel) to support lseek(2). My current fix retuns 0 for
this case. But if your read(2) 1000 bytes and lseek(2) to 0 (full
rewind), and read(2) will return 1000 again.
Is it acceptable for you?
J. R. Okajima
60.451:12): apparmor="DENIED"
operation="open" profile="man_groff"
name="/live/image/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.25" pid=1441
comm="troff" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
These msgs looks matching the strace logfile, and expains the problem.
But I don't know why AppArmor denied the access.
Does your AppArmor setting allow reading "/etc/ld.so.cache" and
"/usr/lib/x86_64-linux-gnu/*.so*", but deny for "/live/image/..."?
J. R. Okajima
Ben Hutchings:
> I think I noticed this a while ago, but since Debian doesn't run on
> nommu systems I didn't bother fixing it.
Arg, nommu.
So it doesn't seem to be related to his problem.
Hmm, I have to read the debian kernel source files carefully.
Give me some time.
J. R. Okajima
1, and found the patch is already applied.
Great debian. :-)
It means aufs4-mmap.patch is unrelated to this problem. Ouch.
Could you put your /live/image iso9660 file somewhere I can reach, so
that I will try man(1) command on aufs with tmpfs+iso9600.
J. R. Okajima
since I am fixing and testing another issue since
last week. The test takes very long time. Please be patient for a
while.
J. R. Okajima
by James B.
- note that aufs5-linux.git#master branch is still linux-v5.3. so
aufs5.x-rcN branch is equivalent to aufs5.3 branch.
o todo
- fix proc_mount.patch to support lseek(2), reported by James B.
- follow the behaviour of NFS acl on linux-v5.2.
J. R. Okajima
compiler
J. R. Okajima
- aufs4-linux.git
aufs doc: fix a few missing words
aufs: bugfix, dirren off-by-one
aufs: minor bugfix, stop exposing kconfig to userspace
- aufs4-standalone.git
ditto
- aufs5-linux.git
ditto
- aufs5
o bugfix
- possible kmemleak
I don't know why, but kmemleak reported a few kfree_rcu()ed memory.
Replaced that kfree_rcu() by kfree().
J. R. Okajima
- aufs4-linux.git
aufs: bugfix, possible kmemleak
- aufs4-standalone.git
ditto
- aufs5
This release is just to follow the changes in mainline v5.6-rc2.
There is no new feature nor bugfix.
J. R. Okajima
- aufs4-linux.git
nothing
- aufs4-standalone.git
ditto
- aufs5-linux.git#aufs5.0..aufs5.5
ditto
- aufs5-linux.git#aufs5.x-rcN
o misc
- tiny, update the year in Copyright
J. R. Okajima
- aufs4-linux.git
aufs: tiny, update the year in Copyright
for aufs mmap: tiny, update the year in Copyright
- aufs4-standalone.git
ditto
- aufs5-linux.git
ditto
- aufs5
ilesystem test suite should be enough. Just what you
will do is
- prepare branch filesystems for aufs.
- mount aufs.
- cd and run some generic tests.
The web pages just mentions about my local tests.
J. R. Okajima
mkdir -p dirA/dirB
echo au > dirA/dirB/fileC
echo au > dirA/dirB/fileD
f dirA dirA/dirB
sudo mount -o bind $tmp.tA dirA
f dirA dirA/tB
sudo umount dirA
sudo mount -o bind $tmp.tA/tB/fC dirA/dirB/fileC
f dirA dirA/dirB
sudo umount dirA/dirB/fileC
set +x
rm -fr $tmp.*
cd
Umount
J. R. Okajima
o news
- a new branch, aufs5.5 for linux-v5.5
J. R. Okajima
- aufs4-linux.git
nothing new
- aufs4-standalone.git
ditto
- aufs5-linux.git
nothing but new branch aufs5.5
- aufs5-standalone.git
ditto
- aufs-util.git
nothing
o bugfix
- aufs-util.git aubusy: possbile bugfix, hexdecimal dev number in a script
aufs5-linux.git#master is still linux-v5.5.
J. R. Okajima
- aufs4-linux.git
nothing
- aufs4-standalone.git
nothing
- aufs5-linux.git
nothing
- aufs5
of NFSv3 doesn't seem stable since v5.2-rc1 (I'm still
investigating)
o misc
- for v5.3, new headers_install scheme
- for v5.5-rc1, remove an arg from rwsem_release()
- I am waiting for the reply on apparmor ML about its 'alias' rule.
J. R. Okajima
o bugfix
- possible bugfix, for userspace use limits.h instead of linux/limits.h
o misc
- for aufs: cosmetic level changes
this commit modifes some files in mainline (and the patch files in
aufs[45]-standalone.git).
- tiny, cosmetic level changes
J. R. Okajima
the wire. In the
future this will hopefully be mitigated by an open file cache, as well
as various optimizations in NFS for this specific case.
Waoh, I didn't know that. But it explains your case well.
NFS client can export nfs-mount on himself, but this re-exporting is
supported by nfs4 onl
The branch filesystem must support NFS\-exporting.
Your branch fs /mail/prod/0[13] are nfs and they don't support
NFS\-exporting itself.
I don't know why /mail/03, nfs4 on CLIENTc7.
Is it stably working? Is it OK if you try giving some heavy workloads
on CLIENTc7?
J. R. Okajima
o news
- linux-v5.6 is released, so do aufs5.6.
aufs code is essentially unchanged since last release.
People are suffering from coronavirus.
Applausing medical workers is good.
Joining and donating CPU to Folding@home or BOINC Rosetta@home is good
too.
I hope world gets better soon.
J. R
behaviour which you think to be incorrect
- actual operation, reproducible one is better
--------
J. R. Okajima
n't care)
Anyway using ACL requires CONFIG_AUFS_XATTR (because ACL is a kind of
XATTR. Linux implements it so). I'd suggest you to confirm whether this
configuration is enabled or not as a first step.
J. R. Okajima
jon bird:
> The good news, firstly no kernel crash and secondly it looks like the
> labels are being propagated upwards correctly. My simple test program
:::
Glad to hear that.
Thank your for your test and report.
J. R. Okajima
o bugfix
- support for selinux, reported by jon bird
o minor
- use FAM (flexible-array member)
J. R. Okajima
- aufs4-linux.git
aufs: minor, use FAM
aufs: bugfix, support for selinux
- aufs4-standalone.git
ditto
- aufs5-linux.git
ditto
selinux policy.
If you have 'seinfo' command, try seinfo --fs_use.
J. R. Okajima
on?
No.
This is an obsoleted function which tried support posix_acl BEFORE linux
mainline established a concrete scheme for xattr. After the scheme is
fixed, those functions were commented out.
J. R. Okajima
But we can check those setting if you can run "seinfo
--fs_use".
My current guess is
- it is not aufs that doesn't support selinux.
- it is selinux that doesn't support aufs.
Do I make myself clear with my broken English?
J. R. Okajima
ch
filesystem. And they may differ from each other. When the lower RO
branch is ext2 and the upper RW branch is tmpfs, even if the size of
file is 0, stat(1) reports Blocks=2 on ext2, and Blocks=0 on tmpfs.
So "diff outA outB" reports "Something is wrong!!", and the test stops.
see how good or bad aufs supports xattr.
Good luck and enjoy.
J. R. Okajima
"J. R. Okajima":
> Unfortunately this Call Trace looks unreliable, and I cannot see the
> behaviour exactly. But I can assume that there is a call chain such
> like this.
> - "ls" issues lgetxattr(2)
> + SyS_lgetxattr()
> + aufs_getxattr()
>
ent,
whether aufs complained about XATTR on nfs.
J. R. Okajima
nfs client create and write
to a file on nfs server.
J. R. Okajima
rmitted
Before diving into these strace logs, I'd want you to confirm one more
thing.
Are there any msg left from your AppArmor or any other LSM? If you stop
all LSM temporarly and test again, what will happen?
J. R. Okajima
ys/module/aufs/parameter/debug
# strace chown apt:root ./aaae
# echo 0 >> /sys/module/aufs/parameter/debug
and show me the strace output and the kernel log.
Just to make sure, you coundn't find any related msg in your LSM logs,
right? And this is unrelated to capability, right?
J. R. Okajima
uld I show you the log file of the nfs
> server side ?
As a next step,
- define your test command such as "touch newfile" or "rm oldfile"
- run "strace touch newfile" and send me the output
- and check the kernel log when you ran "touch newfile"
J. R. Okajima
"hom...@163.com":
> Attachments is the output in the unpreviliged container and parent server.
I cannot see any error in your "strace touch newfile in unpreviliged
containers.txt" and "strace touch newfile in parent server.txt".
Please define a command to reproduce the error.
J. R. Okajima
"hom...@163.com":
> Please refer to the attachment.
I am afraid you forgot the kernel log.
J. R. Okajima
uming the kernel splats some msgs but you don't recieve them, let's
try this.
# id
# cat /proc/sys/kernel/printk
(assume "4 4 1 7")
# echo 8 >> /proc/sys/kernel/printk
# strace chown apt:root ./aaae
# echo 4 >> /proc/sys/kernel/printk
(here '4' is the first value of the original)
J. R. Okajima
nfiguration (define/undefine CONFIG_AUFS_xxx)
- kernel configuration or /proc/config.gz (if you have it)
- LSM (linux security module, if you are using)
- behaviour which you think to be incorrect
J. R. Okajima
the request correctly, then it
means the problem exists on the server side.
Can you try packet dumping?
J. R. Okajima
iven to xino must be a new one since aufs will create it.
But why do you want to add xino=? Any particular reason?
J. R. Okajima
for NFS SETATTR request.
I'd suggest you to check the parameters in the request packet first.
J. R. Okajima
"hom...@163.com":
> Does aufs has the interface that I can use to write a hook to replace
> some functions, like "chown" in aufs' VFS interface?
No, but linux kernel has a feature called KPROBE.
See Documentation/kprobes.txt.
J. R. Okajima
yslog:
>
> SELinux: initialized (dev aufs, type aufs), not configured for labeling
How does selinux know whether the filesystem supports labeling or not?
If something more than XATTR is necessary, tell me about it.
Also you should check your kernel whether CONFIG_AUFS_XATTR is enabled.
J. R. Okajima
Last but not at least, as you might know, aufs3.16 is NOT maintained
anymore. It had stopped since Oct 2015. Additionally I've replaced my
test PC last year. It is intel core5 9th generation. I am afraid
aufs3.16 cannot run on such new machine. Don't expect me that I can
reproduce the problem on my side.
J. R. Okajima
security policy?
Does it support aufs? How is your "seinfo --fs_use"?
J. R. Okajima
have
higher priority.
I shall return to aufs5.x-rcN in a few months.
Thanx for your patience.
J. R. Okajima
o news
- linux-v5.7 is released. so is aufs5.7 branch.
aufs5.8-rcN is not started yet.
o bugfix
- do not call i_readcount_inc(), reported and fixed by Mauricio Faria de
Oliveira.
- related to above, fix IMA i_readcount.
J. R. Okajima
- aufs4
already been published).
Do you mean it is too late?
Maybe you are right. Actually I had some irregular issues recently.
But you could use aufs5.x-rcN branch for linux-v5.7 (or linux-v5.7-rcN).
I believe linux-v5.7 users had NOT met a trouble like aufs is not
available.
J. R. Okajima
proc_mounts.patch is not necessary anymore.
I am going to remove proc_mounts.patch from aufs release, and revert a
few commits in aufs-util.git whose major parts were developed by Kir.
If you can, could you confirm the behaviour of /proc/mounts in v5.8 and
post the result here?
J. R. Okajima
Hello all,
I am going back to aufs development, and a new release will come early
in next year (aufs5.{8,9,10}). Also I am going to stop supporting
aufs4.19--aufs5.3 branches.
My new development base version is aufs5.4.
J. R. Okajima
f_op->read() and ->write() functions.
J. R. Okajima
- aufs5-linux.git#aufs5.4..aufs5.7
aufs: minor, pseudo keyword 'fallthrough'
aufs: minor, MAINTAINERS
aufs: cosmetic, fix a comment
- aufs5-linux.git#aufs5.8
Addition to
Aufs5.10 branch in Last release was broken and all patch files were
missing. Sorry it was my fault. This release contains real aufs5.10.
J. R. Okajima
- aufs5-linux.git#aufs5.4..aufs5.9
nothing
- aufs5-linux.git#aufs5.10
aufs: version 5.10
Aufs5.10 branch in Last release was broken and all patch files were
missing. Sorry it was my fault. This release contains real aufs5.10.
J. R. Okajima
- aufs5-linux.git#aufs5.4..aufs5.9
nothing
- aufs5-linux.git#aufs5.10
aufs: version 5.10
nline.
J. R. Okajima
si=..." as mount command option.
J. R. Okajima
dan:
> I'm running ubuntu 20.04 and I can't find what's missing to get the
> mount command, or /proc/mounts to reflect the current branches in an
> aufs mount.
To see the current branches, refer to /sys/fs/aufs/si_*/*.
J. R. Okajima
o news
- linux-v5.13 is released, and aufs-5.13 follows it.
no new commits
J. R. Okajima
o news
- linux-v5.12 was released, and aufs5.12 branch too.
Essentially nothing is changed from previous aufs5.x-rcN branch.
J. R. Okajima
by my local
git-work. Fixed.
J. R. Okajima
- aufs5-linux.git#aufs5.4..aufs5.11
nothing
- aufs5-linux.git#aufs5.x-rcN
aufs: v5.12-rc1 idmapper userns 1/2, new parameter
aufs: v5.12-rc1 idmapper userns 2/2, set path->mnt earlier
- au
o bugfix
- doc abi, compatible to sphinx or reStructuredText, reported on github
by GI Jack.
J. R. Okajima
- aufs5-linux.git
aufs: doc abi, compatible to sphinx or reStructuredText
aufs: minor, comment about f_op->splice_{read,wr
o bugfix
- rwsem-check under no LOCKDEP, reported by Zhengyuan Liu.
J. R. Okajima
- aufs5-linux.git
aufs bugfix: rwsem-check under no LOCKDEP
- aufs5-standalone.git
ditto
- aufs-util.git
nothing
o news
- nothing new. just updated and aufs5.11 branch added.
J. R. Okajima
the file capability? It
should be kept, isn't it?
If you tried "cp" instead of "mv, then the file capability should be
dropped.
Am I wrong?
Anyway, I think there is a problem in aufs since "cp" seems to keep the
file capability as you posted. I am still trying to understand the
details now.
J. R. Okajima
le capability
+ sudo cp -a u/true2 u/trueD
+ getcap -v rw/trueD u/trueD
rw/trueD = cap_sys_admin+ep
u/trueD = cap_sys_admin+ep
# case 5: simple copy-up keeps the file capability
+ touch ./true2
+ getcap -v ro/true2 u/true2
ro/true2 = cap_sys_admin+ep
u/true2 = cap_sys_admin+ep
All these behaviours look correct.
What am I missing?
J. R. Okajima
o news
- linux-v5.14 is released, and new branch "aufs5.14" too
o misc.
- minor, update the copyright year
I just simply forgot it.
As I announced on 19 Jul, aufs5.4..aufs5.9 end. They are not supported
anymore. My new development base version 5.10.
J.
o news
- aufs5.10 branch and later in aufs5-standalone.git, introduce an extra
patch for RT-patched kernel by He Zhe.
J. R. Okajima
- aufs5-linux.git
nothing
- aufs5-standalone.git#aufs5.4..aufs5.9
nothing
- aufs5-standalone.git#aufs5.10..aufs5.x
aufs
users want such patch. If there is a large community of RT users, your
patch will be included in aufs5-standalone git as separate
rt-compat.patch.
J. R. Okajima
o bugfix
- stop omitting path->mnt, reported and originally patched by Mauricio
Faria de Oliveira.
J. R. Okajima
- aufs5-linux.git
aufs: bugfix, stop omitting path->mnt
aufs: support FUSE branch a little more
- aufs5-standalone.git
o news
- aufs began supporting v5.15 series.
J. R. Okajima
- aufs5-linux.git#aufs5.10..aufs5.14
nothing
- aufs5-linux.git#aufs5.x-rcN
aufs: for v5.15-rc1, no mand-lock anymore
aufs: for v5.15-rc1, new param 'rcu' for ->get_acl()
a
o news
- the development of aufs5.x-rcN for v5.16-rc1 started
now aufs5.x-rcN branch simply follows the changes in mainline.
J. R. Okajima
- aufs5-linux.git#aufs5.10..aufs5.15
nothing
- aufs5-linux.git#aufs5.x-rcN
aufs: v5.16-rc1, use
o news
- aufs5.10.82 and aufs5.15.5 branches just to follow the changes in
mainline/stable
- aufs5.15, restore missing "rt.patch"
J. R. Okajima
- aufs5-linux.git
aufs5.10.82 and aufs5.15.5 branches
- aufs5-linux.git#aufs5.15
resto
1 - 100 of 149 matches
Mail list logo
