Arun Chandran:
> ---------------------------------------------
> Files in the layers before mounting
> ----------------------------------------------
> # for i in `find layer* `; do chsmack $i; done
> layer0 access="k1"
> layer0/0.txt access="k1"
> layer1 access="k1"
> layer1/1.txt access="k1"
At this point, won't you try these steps?
If a normal user cannot complete them, try as a superuser too.
Of course I am assuming the smack options are set to layer1.
cd ./layer1
> .wh..wh.aufs
ln .wh..wh.aufs .wh.0.txt
> layer1/.wh..wh.aufs access="_" --------------> These meta data files
> are labelled "_"
> layer1/.wh..wh.plnk access="_"
> layer1/.wh..wh.orph access="_"
:::
> Am I clear now?
No.
- Is the root cause of your problem that .wh..wh.aufs has access="_"?
- If so, why does it have access="_"? A simple creat(2) doesn't set the
attribute you want?
- If creat(2) is not good enough, then what is the correct way?
In order to give the light to these questions, I am asking the test of
creat(2) and link(2) manually. How can you get the result you want
manually?
> This option will chose the supplied smack label (k1) for the newly
> created aufs meta data files.
> In my case you can see the aufs meta data files (.wh..*.*) are labelled as
> "_".
>
> [This is happening because new objects get the label of subject. These
> files are created while mounting as a root user. The smack label for
> root user is "_". ]
I am afraid such option violates the security policy of branch fs's or
smacks's. If it is acceptable, then why don't you set other label to
.wh..wh.aufs manually after mount(2)?
Is this a natural-born-problem from a mixed use-case of smack and how
you mount aufs?
- the smack label for root user is "_".
- aufs creates .wh..wh.aufs at mounting.
- you mount aufs as root.
Then .wh..wh.aufs has "_" obviously. And there may exist another way you
can take such as,
- mount aufs by a user other than root.
+ that user has to have a capability to isseu mount(2) and other
necessary syscalls.
+ the smack label for that user should not be "_".
If necesssary, I will refine the capability in aufs. It will be much
better than violating the security policy.
J. R. Okajima
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
