Moved my system to a new SSD, by tar, and came to the conclusion that posix capabilities should be accounted for (didn't use --acls/--xattrs on tar, -p isn't sufficient for this). This led to issues as I was no longer able, among other things, to unlock my screen as /sbin/unix_chkpwd had it's capabilities removed. It threw errors in the logs the user doesn't exist. Presume because of the lack of capabilities it's not allowed to read /etc/passwd|shadow or similar. Would be nice if qcheck would be able to handle this. The capabilities are quite important for the system to function correctly and as such I'd consider it very useful/desirable for qcheck to be able to detect issues with them.
I'm affraid Portage doesn't store this info in the VDB anywhere. @portage: is there a place where we keep track of file modes, capabilities and permissions?
(In reply to Fabian Groffen from comment #1) > I'm affraid Portage doesn't store this info in the VDB anywhere. No, but /var/db/pkg/*/*/BUILD_TIME files can be used to associate an installed package with its corresponding binary package instance. > @portage: is there a place where we keep track of file modes, capabilities > and permissions? If the corresponding binary package available in ${PKGDIR} then it's possible to read these things from the tar entries. The capabilities are in the pax_headers which you can see in this commit: https://gitweb.gentoo.org/proj/portage.git/commit/?id=1032cbf4c218741df1c57767fead2d00cc6321d9
I can get around it, be it cumbersome. Would be nice if qcheck would validate this. Someone in #gentoo also stated he would appreciate this, although he found it more interesting for checking the file permissions / state of the system for security reasons (as in was bash not given suid, or do other files have more permissions/abilities than they should by default). Think it would certainly have value both ways.
@Zac: what do you think about adding ownership, modes and attrs to the VDB? It sounds useful to me. Does that need EAPI stuff?
(In reply to Fabian Groffen from comment #4) > @Zac: what do you think about adding ownership, modes and attrs to the VDB? Yes, we could also include more secure digest(s) than MD5 (bug 605082). Maybe json would be a good format, for extensiblility. > It sounds useful to me. Does that need EAPI stuff? It's not covered by either PMS or EAPI (see bug 458866).
for tools like q using flat formats really is easier :) If noone beats me to it, I'll give it a try to add another function to misc-functions.sh or where the stuff for NEEDED entries lives today.
(In reply to Fabian Groffen from comment #6) > for tools like q using flat formats really is easier :) In order to make CONTENTS extensible, without changing the format, we can introduce separate files that are assumed to contain parallel data just like parallel arrays. That way, the file paths only need to be stored once, and we can extend the data associated with those paths by adding new files that have exactly the same order and number of lines.
That works for me, however, is it worth saving those bytes (using fname as pkey)? (In contrast to having it duplicated indeed, but allowing to "join" the files or quickly grep the right entry out of it?)
Grep it not really the right tool for the job. If we avoid data duplication, CONTENTS has become infinitely extensible without wasting any space. We can extend it as much as we want, without hesitation.
ok, that could work
(In reply to Fabian Groffen from comment #1) > I'm affraid Portage doesn't store this info in the VDB anywhere. > > @portage: is there a place where we keep track of file modes, capabilities > and permissions? A patch is now proposed in Bug 605082 to record this. If people are happy with it, I'll have a go at the needed changes to qcheck.
Not a lot of comments on the other bug, so also no critique, I guess :D I'm going to start working on this in the coming period. Sent a pull request for a first clean-up of qcheck. Will proceed with additional changes.
Seems to be working, see https://github.com/sbesl/portage-utils This depends on the patches in Bug #605082
just letting you know, I'm waiting for this to land in portage, then I'll include your patch