Closed peabee closed 2 years ago
Can you share cat $(which chromium)
too? And what is your working directory when you try to start Chromium?
This same savefolder has been in use for some considerable time........
I have found that removing /etc/passwd from the savefolder makes an "improvement" in that the really crazy errors disappear. The errors then are:
# chromium
[0314/165958.050410:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2)
[0314/165958.050546:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2)
/usr/bin/chromium: line 28: 6464 Trace/breakpoint trap run-as-spot /opt/chromium/chromium $switches --disk-cache-size=10000000 --media-cache-size=10000000 --allow-outdated-plugins "$@"
When run in a terminal as above the working directory is /root
The full chromium wrapper contents are:
#!/bin/sh
# Chromium32-Void run-as-spot launcher 130222
BROWSER=chromium
export LD_LIBRARY_PATH=/opt/chromium:$LD_LIBRARY_PATH
export CHROME_VERSION_EXTRA="from Void packaged for Puppy Linux Run-As-Spot"
switches="--disable-seccomp-filter-sandbox -test-type"
#switches="-test-type"
if [ ! -f /opt/chromium/chromium-spotrun1 ]; then
touch /opt/chromium/chromium-spotrun1
Xdialog --title "Default Browser" --yesno "REMINDER: $BROWSER is Run-As-Spot \n Would you like $BROWSER to be \n the default browser?" 0 0
case $? in
0)cp /usr/local/bin/defaultbrowser /usr/local/bin/ORIGdefaultbrowser
echo '#!/bin/sh
exec '"$BROWSER"' "$@"' > /usr/local/bin/defaultbrowser ;;
*) ;;
esac
glib-compile-schemas /usr/share/glib-2.0/schemas
# if system has gtk-3 remove version in .sfs
[ ! "`ls /usr/lib/libgtk-3.so*`" = "" ] && rm /opt/chromium/libgtk-3.so*
[ ! "`ls /usr/lib/libgdk-3.so*`" = "" ] && rm /opt/chromium/libgdk-3.so*
[ ! "`ls /usr/lib/i386-linux-gnu/libgtk-3.so*`" = "" ] && rm /opt/chromium/libgtk-3.so*
[ ! "`ls /usr/lib/i386-linux-gnu/libgdk-3.so*`" = "" ] && rm /opt/chromium/libgdk-3.so*
fi
run-as-spot /opt/chromium/chromium $switches --disk-cache-size=10000000 --media-cache-size=10000000 --allow-outdated-plugins "$@"
chown -R root:root /root/spot/Downloads/*
/usr/lib/gtkdialog/box_splash -placement center -bg yellow -fg black -timeout 4 -text "REMINDER: Any downloads will have SPOT ownership but any items in /root/spot/Downloads have been changed to ROOT ownership" &
Can you share the contents of /usr/sbin/run-as-spot
? Let's see if it's identical to the one in testing
I have found that removing /etc/passwd
What were the contents of the modified /etc/passwd? Is there any chance that spot had /root/spot as its home directory?
Yes it did.
So the question is, why spot's home directory was changed?
spot in /etc/passwd was changed 4 years ago but the 'old' version in my savefolder has not caused problems until the recent changes between testing;183808e0f;2022-02-22 and testing;e7ef674a8;2022-03-11 i.e. https://github.com/puppylinux-woof-CE/woof-CE/commit/9c0a061f8eb4695326063ed00a618ec649b09644
916d6614276eada9e58a25e0b70e931227840087 makes spot unable to read files under /root (it can no longer dereference the /root/spot symlink), so it can't do stuff like leaking sensitive files like .netrc. Without this, a browser running as spot provides a very small degree of isolation.
This is probably the commit that 'broke' your save file, not 9c0a061f8eb4695326063ed00a618ec649b09644.
You probably ran passwd
at some point to change your password, before the time spot's home directory got moved outside of /root. You kept using that modified /etc/passwd, even after spot's home directory was changed. Things worked only because spot was able to dereference /root/spot, until 916d6614276eada9e58a25e0b70e931227840087, which finally isolates /root from spot (the unfulfilled motivation behind 9c0a061f8eb4695326063ed00a618ec649b09644).
The only 'bug' here is that you kept using an old /etc/passwd, and carried it between incompatible Puppy versions.
I don't use run-as-spot for security reasons - I use it because some apps refuse to run as root and therefore constrain my wish to use them..... I accept that my savefolder has been in existence for some time however you will see that the /etc/passwd change for spot's home directory explicitly says that the change to /home/spot would not affect any existing systems - and indeed for 4 years it hasn't and I didn't need to change it. My savefolder is not 'broken' other than in respect of run-as-spot which has now stopped working since the recent changes. What do I need to revert so that run-as-spot behaves as it used to?
What do I need to revert so that run-as-spot behaves as it used to?
I tried a build with that line 907 commented out... With the savefolder I still get the errors reported above....
# chromium
[0314/165958.050410:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2)
[0314/165958.050546:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2)
/usr/bin/chromium: line 28: 6464 Trace/breakpoint trap run-as-spot /opt/chromium/chromium $switches --disk-cache-size=10000000 --media-cache-size=10000000 --allow-outdated-plugins "$@"
With a pristine boot with no savearea I don't get the errors and chromium starts as expected
In both cases the /sys/devices/system/cpu/cpu0/cpufreq/ files do not exist.
I think that /root inherits the permissions from the version in the savefolder anyway?
This is not related to /root permissions ...
I understand that ........ but it has arisen between testing;183808e0f;2022-02-22 and testing;e7ef674a8;2022-03-11 so presumably is caused by a woof-ce change which is no longer compatible with some content in my savefolder......
That's extremely unlikely, but a kernel update is a super likely explanation.
If /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq doesn't exist, this has nothing to do with spot's home directory.
I am using the same kernel in both tests - with savefolder and without savefolder..... But I will try a different kernel to see if that makes any difference....
There's a variety of reasons for /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq to be missing, none of them are related to spot.
Maybe you should try to modprobe cpufreq_ondemand
.
Tried changing kernel (to kernel-kit 5.10) - no difference Tried modprobe - no difference Guess I'm going to have to give up and start the laborious process of constructing a new savefolder from scratch - sigh!! Just have to hope it doesn't catch anybody else with an existing savearea .... maybe nobody will have one as old as mine ....
If you boot with pfix=ram
, do you still see this error? If no, check if /etc/modprobe.d or the kernel command-line blacklists one of the various cpufreq drivers.
If you boot with
pfix=ram
, do you still see this error? If no, check if /etc/modprobe.d or the kernel command-line blacklists one of the various cpufreq drivers.
No - thats what I mean when I say "boot with no savefolder" There is an /etc/modprobe.d/blacklist.conf in the savefolder but it doesn't have anything with cpufreq in it. Nothing in menu.lst either for kernel command-line.
Thank you for your help....... With 2 changes:
The problem has "gone away" - not entirely sure why but happy that it has. Thanks.
With: BUILD_FROM_WOOF='testing;183808e0f;2022-02-22 06:38:57 +0000' this wrapper for chromium to run-as-spot works fine:
After a new build with an updated woof-ce, but still using the same savefolder: BUILD_FROM_WOOF='testing;e7ef674a8;2022-03-11 08:36:05 +0200' the same wrapper crashes:
With a pristine boot with no savefolder, the crash does not occur ....... so something in the original savefolder is preventing the "new" run-as-spot from working.
I really don't want to have to start again with a fresh savefolder if I can possibly help it - so what in the savefolder might be causing these errors??