Summary: | savedconfig.eclass doesnt decode user misuse of perms in /etc/portage/savedconfig/ | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Roger <rogerx.oss> |
Component: | Eclasses | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arfrever |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Roger
2009-10-15 06:58:22 UTC
It's alright to set whatever permissions you want on /etc/portage, and portage should only bail out or warn if absolutely necessary. In this case, it's savedconfig.eclass that's bailing out, and we might be able to improve the error message a little. Think I"ve got things setup to where portage is using sandbox, or portage.portage (owner.group) permissions. As such, if portage encounters a "read only for owner" root, portage will bail with failing to read/access. So, either files should be set world readable if owned by root, or put them into group portage or as owner portage. (?) <shrugs> ... I've just be manually chmod'ing on an as need to basis. (In reply to comment #3) '[[ -r ${base} ]]' probably should be changed to '[[ ! -r ${base} ]]'. (lol @ error message...) ... blunt works for me, too. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c3c88c805320021786d2bb925918e9ba2d15c79d commit c3c88c805320021786d2bb925918e9ba2d15c79d Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2021-09-26 23:47:13 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2021-09-29 19:32:44 +0000 savedconfig.eclass: drop faulty permissions check This check was meant to test if the user has accidentally restricted access to the /etc/portage/savedconfig directory. There are a few problems: 1. We don't actually need read access on the directory. We really need the execute bit set so that we can access files within the directory. 2. There may be permissions issues on subdirectories, and we would fail to detect them. 3. There is no easy way to distingish between EACCES and ENOENT using shell commands. We get an exit status of 1 from [[ -r ${path} ]] if there is a permissions problem or if some component of the path does not exist. This makes resolving problem 2 difficult without using a more robust language with direct access to errno. Instead of trying to detect a permissions problem, just output a warning telling the user to check permissions if we cannot find a config file. Bug: https://bugs.gentoo.org/289168 Bug: https://bugs.gentoo.org/814995 Signed-off-by: Mike Gilbert <floppym@gentoo.org> eclass/savedconfig.eclass | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) |