Thread Info
  • State Not Answered
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 16 replies
  • Subscribers 11 subscribers
  • Views 33804 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
  • 0

    syslog should show why talpa blocked access to /usr/src/linux-headers-4.10.0-22-generic/include/config/dw/dmac/core.h.dpkg-new

     

    # grep talpa /var/log/syslog

     

    The only errors I could see in the bug were segfaults.

  • 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.

Reply
  • 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.

Children
Unfiltered HTML