This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

new Astaro::ConfdPlRPC() fails

I recently updated my Sophos UTM to 9.508-10, and now a script that I run on the server (as loginuser) no longer works. It appears to be hanging on this command:

my $sys = new Astaro::ConfdPlRPC();

Has something changed with this release to where this is no longer supported, or do I need to change something in the admin portal?



This thread was automatically locked due to age.
Parents
  • I observed the same with such a script (related to letsencrypt).

    If the script is run as root per sudo, it does not hang and performs its desired task. It would be nice if this could (again) be done as loginuser.

  • Wouldn't you think it a security problem if configuration changes could be made by the loginuser?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • BAlfson said:

    Wouldn't you think it a security problem if configuration changes could be made by the loginuser?

    Hm, you are right of course. In that case however, this security problem has been left open for quite a while (the letsencrypt-solution I linked to in my above post was submitted to GitHub on 02 Nov 2016, and presumably not because the security problem was new, but rather because letsencrypt was new).

    Apart from this, it looks to me that locking out loginuser is only a (possibly welcome) accidental side-effect here, for otherwise I would expect the new to fail with an error instead of a hang (in fact, I'd expect an error only later in the process when the object was used to read/write anything).

    But in spite of all my frustated ranting, you are of course right (I always consider your avatar a seal of quality). I suppose I'll have to look into converting to REST ...

Reply
  • BAlfson said:

    Wouldn't you think it a security problem if configuration changes could be made by the loginuser?

    Hm, you are right of course. In that case however, this security problem has been left open for quite a while (the letsencrypt-solution I linked to in my above post was submitted to GitHub on 02 Nov 2016, and presumably not because the security problem was new, but rather because letsencrypt was new).

    Apart from this, it looks to me that locking out loginuser is only a (possibly welcome) accidental side-effect here, for otherwise I would expect the new to fail with an error instead of a hang (in fact, I'd expect an error only later in the process when the object was used to read/write anything).

    But in spite of all my frustated ranting, you are of course right (I always consider your avatar a seal of quality). I suppose I'll have to look into converting to REST ...

Children
No Data