Again, it has been two weeks since my last report, shame on me. But my exams are all written by now (and passed :D) and I have some exciting new stuff to tell you :).
What did I do this week (and the last):
The next step in this project was to find out why and where the caps get lost, when they are set in src_install (that means on the binary in the sandbox and not on the binary which is already in the livefs).
After a long and sometimes frustrating journey through the portage sources and with a lot help from pdb I found out why.
Normally (e.g. when the source and the destination are on the same filesystem) os.rename is used to move the binary from sandbox to livefs. This happens in portage/pym/portage/util/movefile.py and is not were the caps are lost.
They are lost earlier, when the binaries are stripped. So I added a preserving-mechanism to portage/bin/ebuild-helpers/prepstrip, where the stripping happens. And it worked :). I could set the caps in src_install and they did not get lost.
But there was another place where the caps could get lost. If os.rename in movefile.py fails or src and dest are not on the same filesystem, shutil.copy is used before os.rename and the binarys mode/ownership are restored after. Of course the extended attributes, like caps, have to be restored, too. Using pyxattr I extracted the caps before the copy and applied them back after the binary is copied and its mode/ownership are restored. The downside is, that portage now needs pyxattr.
With that now working, I changed all ebuilds I have patched so far, so the caps are set in src_install.
I added the changed ebuilds and the changed portage-files to a new branch in my repository. I used the current stable version (2.1.8.3) of portage, just so you know :).
That’s it for today, tell me what you think in the comments :).
Cool :) thanks! are there any plans already to merge your changes to the portage source?
Looking forward to see this work hitting stable tree! Hopefully it will also work with binary packages and gracefully downgrade to suid if $ROOT does not support xattr/capabilities even though $PORTAGE_TMP does.
I don’t know when or if it will be included in portage, it’s not reviewed, yet :).
I’m currently working on a fallback-mechanism if the target-filesystem doesn’t support xattrs.
Concerning BINPKGs: I already tried it with a patched version of tar which has xattr-support (patch is from fedora’s tar) – works without problems, but needs more testing on different systems!
Do you really need a fallback? Just make xattr support in the filesystem a requirement.