| Summary: | Portage tries to open /root/.bash_history with FEATURES=userpriv | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jocelyn Mayer <l_indien> |
| Component: | Current packages | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | billie, wschlich |
| Priority: | High | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 268228 | ||
| Attachments: |
emerge.info
sample ebuild output environment filter the HISTFILE variable |
||
|
Description
Jocelyn Mayer
2004-11-18 01:42:39 UTC
All I can find on this is an emerge --debug log on bug #62589 showing that /root/.bash_history should be in SANDBOX_WRITE. But presumably that's not the case with FEATURES=userpriv. Not sure how to resolve this. Portage guys got some idea? Hey, I don't want this process to write into my bash history ! This file is used to store interractive root command line history and it would, in my opinion, be absolutelly unsafe to let other processes than interractive root bash shell write into it. The problem may be there: isn't there a interractive bash launched by the install process ? Another way to (badly) solve the problem would be to unset HISTFILE during install... This isn't a portage problem... It's a very strange build problem. No direction or new information for this bug. Reopen if it recurrs. I am experiencing the same on one specific machine, no matter whatever package I am emerging. Now this was strange. I tried using FEATURES="-userpriv" emerge ... but it did not help. Then I tried FEATURES="-*" emerge ... and it worked. Since that, it also works without specifying FEATURES in the environment I guess something has been reset or changed when running with FEATURES="-*". Any ideas? (In reply to comment #5) > I guess something has been reset or changed when running with FEATURES="-*". > Any ideas? FEATURES="-*" would have disabled both sandbox and and userpriv, so that would have allowed the build have write access to /root/.bash_history. Normally, the value of $HOME is overridden in the ebuild environment so that that only reason something would go for /root is if it's hard coded somewhere in the build system of the package. You can check the /var/db/pkg/*/*/environment.bz2 files to verify that $HOME is correctly set. Closing time or still valid? It's either fixed, never was a portage bug or would need more information to be solved. From time to time I experience this in unpack stage about portage trying to write to my normal users ~/.bash_history. This happens when using sudo as the normal user and also when I su to root before (even there the _users_ history file is accessed). The problem goes away if i remove my ~/.bash_history or change it. Changing means removing a line. What is strange that adding content to the file wont help. So it seems to have nothing to do with the content of the file as it works when removing a random line. Also I do not have FEATURES="userpriv" set. Maybe worth to mention this also happened before the new sandbox-1.6 went stable. Created attachment 189633 [details]
emerge.info
Created attachment 189635 [details]
sample ebuild output
Do you have anything in /etc/portage/bashrc? Please attach the environment file from a failed build. It's path relative to the build directory is temp/environment. Created attachment 189647 [details] environment (In reply to comment #12) > Do you have anything in /etc/portage/bashrc? Please attach the environment file > from a failed build. It's path relative to the build directory is > temp/environment. > No /etc/portage/bashrc. environment file attached. Created attachment 189659 [details, diff]
filter the HISTFILE variable
Please try this patch to see if it helps. If it is saved as /tmp/histfile.patch, then it can be applied as follows:
patch /usr/lib/portage/pym/portage/__init__.py /tmp/histfile.patch
(In reply to comment #14) > Created an attachment (id=189659) [edit] > filter the HISTFILE variable This is in svn r13403. (In reply to comment #15) Excluding the histfile stops the sandbox issues. Thanks. This is fixed in 2.1.6.12 and 2.2_rc32. |
