Thread Info
  • State Not Answered
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 16 replies
  • Subscribers 11 subscribers
  • Views 33871 views
  • Users 0 members are here
Options
Suggested
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

I recently tried to install a new ubuntu kernel (4.10.0-22). It failed, it seems due to Sophos.

pastim

I recently tried to install the latest kernel for ubuntu 17.04 - 4.10.0-22.  It kept failing saying an "operation was not permitted".  When I reported this on the ubuntu bug tracker it was suggested I turn off anti-virus and try again. 

I disabled the on-access scan and tried again, and installation worked.

I had no warnings or alerts from sophos.  I checked that the sophos warnings and emails were on and worked (I tested using the test virus file) and that all worked.

So, somehow sophos is preventing a file access.  I am on the latest version, including talpa.

The ubuntu report with full details is at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1696132 

Regards



This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to DouglasLeeder

    I have 3 systems on ubuntu 17.04 running Sophos, and only one had this problem.   It is a fact that disabling on-access scanning circumvented the crash on the one system, but I've no idea why, nor why the other 2 systems had no problem.  I tried this kernel update many times and it failed every single time on the one system until I did this.

    All I can find in the syslog is this. Is there anything else I can supply that would help?  Note that the 'operation not permitted' error sometimes seemed to happen on different files when I tried installing again.


    Jun 6 14:32:14 ChrisP AptDaemon.Worker: INFO: Processing transaction /org/debian/apt/transaction/80fb41eb7891454a9a34704fc84e3ddf
    Jun 6 14:32:14 ChrisP org.debian.apt[904]: 14:32:14 AptDaemon.Worker [INFO]: Processing transaction /org/debian/apt/transaction/80fb41eb7891454a9a34704fc84e3ddf
    Jun 6 14:33:06 ChrisP NetworkManager[948]: <info> [1496755986.0826] manager: kernel firmware directory '/lib/firmware' changed
    Jun 6 14:33:17 ChrisP AptDaemon.Worker: CRITICAL: /tmp/apt-dpkg-install-qSYV0L/3-linux-image-extra-4.10.0-22-generic_4.10.0-22.24_amd64.deb: unable to open '/lib/modules/4.10.0-22-generic/kernel/drivers/isdn/hisax/sedlbauer_cs.ko.dpkg-new': Operation not permitted
    Jun 6 14:33:17 ChrisP org.debian.apt[904]: 14:33:17 AptDaemon.Worker [CRITICAL]: /tmp/apt-dpkg-install-qSYV0L/3-linux-image-extra-4.10.0-22-generic_4.10.0-22.24_amd64.deb: unable to open '/lib/modules/4.10.0-22-generic/kernel/drivers/isdn/hisax/sedlbauer_cs.ko.dpkg-new': Operation not permitted
    Jun 6 14:33:17 ChrisP kernel: [29149.386737] show_signal_msg: 33 callbacks suppressed
    Jun 6 14:33:17 ChrisP kernel: [29149.386740] aptd[13060]: segfault at 0 ip 00007fbb74c09cfb sp 00007ffe5b30b460 error 4 in libc-2.24.so[7fbb74b9b000+1bd000]
    Jun 6 14:33:36 ChrisP AptDaemon.Worker: INFO: Finished transaction /org/debian/apt/transaction/80fb41eb7891454a9a34704fc84e3ddf

  • 0 in reply to pastim

    Sorry, is on-access enabled with Talpa or fanotify?

     

    I can't see any Talpa messages in syslog, so I'm guessing it might be fanotify, in which case it might be much harder to diagnose why the machine is blocking those files.

     

    The diagnose output might help: https://community.sophos.com/kb/en-us/33556

  • 0 in reply to DouglasLeeder

    I just had a look again, and it turns out that that system was using fanotify, whereas my other 2 were using talpa.  I don't know why (maybe I didn't update talpa properly for the previous kernel updates), but it is now using talpa.

    This may at least explain why 2 systems updated the kernel OK and one wasn't (ie. a fanotify issue).

    Would you like me to submit the diagnose output?  I don't know if it will contain information from 5th/6th june or not.

  • 0 in reply to pastim

    I am unclear whether I can submit the diagnose output or not.  I am using the free unsupported version, so I don't think I have the credentials, ticket etc to do so.  I'll happily do it if there's a way and if it will be helpful to you.  I probably won't be able to test any fix since all is now working OK.

  • 0 in reply to pastim

    Yes, I agree, I'm not sure the logs will show any more information about why fanotify blocked access to the files while installing the update.

     

  • 0 in reply to DouglasLeeder

    If you want me to email the diagnose output to you or some other email address I will happily do so - let me know - it's about 5.4MB.  Otherwise I guess we'll have to leave it.  OK?

  • 0 in reply to pastim

    I think we'll have to leave it. Sorry about that.

  • 0 in reply to DouglasLeeder

    That's OK.  Just trying to help :)

    As a final note, the reason that system was using fanotify rather than talpa was that it didn't have the linux headers for the older kernel I was using to avoid a newer kernel that was crashing the system. So Talpa wasn't compiling, and I wasn't noticing any alerts or looking at any logs that would have told me.  I should check the logs more often!

Unfiltered HTML