Summary: | app-portage/portage-utils - qcheck: add support for acl/xattr | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Ferry <freaky> |
Component: | Tools | Assignee: | Fabian Groffen <grobian> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | dev-portage, gentoo, preed |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=605082 https://bugs.gentoo.org/show_bug.cgi?id=836954 https://bugs.gentoo.org/show_bug.cgi?id=230818 https://bugs.gentoo.org/show_bug.cgi?id=134677 https://bugs.gentoo.org/show_bug.cgi?id=523706 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 193766 |
Description
Ferry
2018-04-26 11:05:40 UTC
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 |