Bug 967183 - SCR crashes (abort) on an empty path inside chroot
SCR crashes (abort) on an empty path inside chroot
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: YaST Team
Jiri Srain
Depends on:
  Show dependency treegraph
Reported: 2016-02-18 09:30 UTC by Martin Vidner
Modified: 2022-08-23 14:05 UTC (History)
2 users (show)

See Also:
Found By: L3
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
jreidinger: needinfo? (mvidner)


Note You need to log in before you can comment on or make changes to this bug.
Description Martin Vidner 2016-02-18 09:30:00 UTC
When fixing an L3* we found what seems to be a regression introduced when implementing SCR target root:

SCR.Read(path(".target.stat"), "") normally returns {}

but if SCR is redirected, it triggers the logic "Root is not absolute, aborting"
(The message is wrong BTW. Root is absolute, but the argument path is not.)

Test case:
$ ruby
require "yast"
handle = Yast::WFM::SCROpen("chroot=/usr:scr", false)
Yast::SCR.Read(Yast::Path.new(".target.stat"), "")
Neúspěšně ukončen (SIGABRT)

Obviously .target.stat is probably only the tip of an iceberg.

We should make SCRAgent::targetPath return an error that is handled by the caller and either resolved entirely or converted to a Ruby exception.

Comment 1 Gabriele Mohr 2016-02-24 12:29:41 UTC
Created PBI on scrum incoming board.
Comment 2 Josef Reidinger 2018-06-07 12:03:44 UTC
Martin: I check code and what I see:

1. log message is wrong and can be change. It now contain also invalid path.
2. How it can be resolved if it gets relative path, but SCR is switched? Should I try to get pwd and if SCRRoot is part of it then just strip it and attach rest of PWD?
3. Ruby exception is not option as it is in yast2-core which does not know anything about ruby. And method to get path relative to SCRRoot return only string, so not much space for error states and c++ exception is something I would like to avoid.

So do you think that tricks in 2 makes sense or should we just keep as it is, as it is programmer error in this case and easily observable in logs?
Comment 3 Josef Reidinger 2018-08-22 13:51:02 UTC
martin - ping
Comment 4 Stefan Hundhammer 2022-08-23 14:05:06 UTC
Martin, is this still relevant after 6 years? Or shouldn't we close this if it's unrealistic that we will do something about this in the forseeable future?