Bug 654122 – app-portage/portage-utils - qcheck: add support for acl/xattr

• Product: Portage Development
• Status: CONFIRMED ---

[Description Ferry 2018-04-26 11:05:40 UTC]

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.

[Comment 1 Fabian Groffen 2018-04-27 10:00:59 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?

[Comment 2 Zac Medico 2018-04-27 15:19:19 UTC]

(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

[Comment 3 Ferry 2018-04-30 08:24:19 UTC]

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.

[Comment 4 Fabian Groffen 2018-04-30 18:00:27 UTC]

@Zac: what do you think about adding ownership, modes and attrs to the VDB?  It sounds useful to me.  Does that need EAPI stuff?

[Comment 5 Zac Medico 2018-04-30 18:54:13 UTC]

(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).

[Comment 6 Fabian Groffen 2018-05-01 06:05:08 UTC]

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.

[Comment 7 Zac Medico 2018-05-01 06:58:36 UTC]

(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.

[Comment 8 Fabian Groffen 2018-05-01 07:06:55 UTC]

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?)

[Comment 9 Zac Medico 2018-05-01 07:23:53 UTC]

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.

[Comment 10 Fabian Groffen 2018-05-01 07:27:57 UTC]

ok, that could work

[Comment 11 Sam 2018-08-08 13:13:31 UTC]

(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.

[Comment 12 Sam 2018-10-25 19:58:10 UTC]

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.

[Comment 13 Sam 2018-11-20 22:30:03 UTC]

Seems to be working, see https://github.com/sbesl/portage-utils

This depends on the patches in Bug #605082

[Comment 14 Fabian Groffen 2018-12-20 18:27:43 UTC]

just letting you know, I'm waiting for this to land in portage, then I'll include your patch