[SOLVED] sbopkg halts with prompt in batch mode

FlinchX · 07-11-2020, 04:51 AM

I am using sbopkg-0.38.1 in Slackware64-14.2.

A few details about my setup:

I run Slackware live edition in VirtualBox (same version as on host). I log there as root so I can play around building and installing packages in a clean environment. But I have a cache directory on the host system (the output directory of a SBo tree for sbopkg) with already built packages, to save time and avoid rebuilding the same packages in the virtual machine multiple times. The cache directory on host is owned by a regular user, not root, and I mount that directory inside the virtual machine over sshfs by logging with that regular user to the host.

I run sbopkg in batch mode with options "-B -e continue" but it still halts to a prompt. It builds a package, then displays the warning about the package ownership not being root:root and asks me to choose between (P)roceeding or (A)borting.

How do I get rid of this prompt and tell sbopkg to ignore the ownership warning and proceed everytime?

bassmadrigal · 07-11-2020, 02:49 PM

You could comment out/remove the while loop that asks that question which will still give you the error but will just continue:

Code:

        while :; do
            read $NFLAG -ep "(P)roceed anyway or (A)bort?: "
            case $REPLY in
                P|p) echo "Proceeding..."; break ;;
                A|a) echo "Aborting..."; return ;;
                *) unknown_response ;;
            esac
        done

Or you can comment out/remove the whole code block that checks for all that:

Code:

    if [[ $(find $INSTDIR/$INSTPKG ! -user root -o ! -group root) ]]; then
        crunch_fmt "WARNING:  The file $INSTPKG is not set with root:root \
            permissions! Here is the output of ls -l:"
        echo
        ls -l $INSTDIR/$INSTPKG
        echo
        while :; do
            read $NFLAG -ep "(P)roceed anyway or (A)bort?: "
            case $REPLY in
                P|p) echo "Proceeding..."; break ;;
                A|a) echo "Aborting..."; return ;;
                *) unknown_response ;;
            esac
        done
    fi

The if statement should start around line 3322 (I don't think I've modified my sbopkg, so I think that should be the line number).

FlinchX · 07-11-2020, 08:58 PM

@bassmadrigal

TBH I'm not prepared to hack into the source code of sbopkg without understanding the implications of doing this.

My best bet is still that I missed the correct way to tell sbopkg to skip this warning via command line options, despite going through the manpage a few times before asking here in forum about it.

If this ends not being the case, I am also considering just exposing the remote cache directory as root, just for the sake of matching ownership of its content. I did not do this by default because I was thinking of principle of least privilege - the same way one doesn't expose files over HTTP as root, but has an user with restricted privileges for running the web server. However, HTTP is mostly read only, while sshfs is fully read write, which makes it slightly different and adds some more complexity.

Modifying sbopkg by hand like you are suggesting would probably be my last option if there's no other way. I think I understand what is the reason for this check. Packages owned by another user could be altered and that opens a gate for inserting malicious content into them, no?

willysr · 07-11-2020, 09:48 PM

that check was made by the original authors (way before i take over maintainership) to make sure it stays consistent with how Slackware packages are made by Patrick.
Some scripts (mostly deb-based scripts) need to ensure the permissions are correctly applied or else it would ruined your whole systems

FlinchX · 07-11-2020, 09:59 PM

@willysr so which one the approaches from my previous post do you recommend? Should I expose the remote package cache as root or just modify the sbopkg source code to skip the warning?

bassmadrigal · 07-11-2020, 10:06 PM

It looks like it is just a warning and there are no current provisions to disable that without either changing things to root or just editing the code.

Personally, I think the easiest thing would be to just edit sbopkg. You can either just remove the code I quotes or just comment it out (adding a # symbol in front of each line.

FlinchX · 07-12-2020, 05:47 AM

I ended with just commenting out that code block indeed. Another option I was considering was to use some hack like expect to automate that key press choice for me, but it seemed more time consuming to implement. Would be nice to have a new command like argument like -e for this scenario in the sbopkg version for 15.0 though.

willysr · 07-12-2020, 11:19 AM

if you can send a PR, then i will gladly review it