Bug 967183

Summary: SCR crashes (abort) on an empty path inside chroot
Product: [openSUSE] openSUSE Tumbleweed Reporter: Martin Vidner <mvidner>
Component: YaST2Assignee: YaST Team <yast-internal>
Status: CONFIRMED --- QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P5 - None CC: jreidinger, mvidner
Version: CurrentFlags: jreidinger: needinfo? (mvidner)
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://trello.com/c/9qmfjwh8
Found By: L3 Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

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?