Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #1223440

Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles

From Julian Gilbey <jdg@debian.org>
Newsgroups linux.debian.bugs.dist
Subject Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles
Date 2024-12-10 10:20 +0100
Message-ID <JS4zo-fM6Z-3@gated-at.bofh.it> (permalink)
References <JRLn3-fpm2-5@gated-at.bofh.it> <JRUJH-fy7X-1@gated-at.bofh.it> <JRLn3-fpm2-5@gated-at.bofh.it> <JRUJH-fy7X-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, Dec 09, 2024 at 10:45:40PM +0000, Richard Lewis wrote:
> On Mon, 9 Dec 2024, 12:42 Julian Gilbey, <jdg@debian.org> wrote:
> 
>   Package: chkrootkit
>   Version: 0.58b-3
>   Severity: normal
> 
>   I was wondering why my /tmp is never cleared by systemd-tmpfiles, and
>   tried playing around with the settings in /etc/tmpfiles.d, but it
>   didn't help.
> 
>   I then discovered the source of the problem: chkrootkit updates the
>   access times of all the files in /tmp as it checks them, meaning that
>   they are always viewed as recently accessed and so never cleaned.
> 
> this is the check for suspicious php files, which does read the start of each
> file to see if it is a php script. 
> 
>   It should
>   therefore record the access time prior to accessing the file and reset
>   it to that time afterwards (presumably using utimes(2) or similar).
> 
> the accessing is done from a shell script so is this even possible? 
> what if someone else accesses the file during the test?

Hi Richard,

Something like this should work in a shell script:

origtime=$(ls --full-time -u "$filename" | cut -d' ' -f6-8)
touch -a --date="$origtime" "$filename"

(though it might need a bit more testing).

Someone else accessing the file during the very short duration of the
test is relatively unlikely, and resetting the access time in such a
relatively uncommon event is not likely to have any significant
negative consequences.  But updating all access times across large
chunks of a filesystem is not at all desirable.  Access times are
usually uninteresting, except in cases such as this (systemd-tmpfiles)
where they are being actively inspected and acted upon.

Best wishes,

   Julian

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Julian Gilbey <jdg@debian.org> - 2024-12-09 13:50 +0100
  Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Richard Lewis <richard.lewis.debian@googlemail.com> - 2024-12-09 23:50 +0100
    Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Julian Gilbey <jdg@debian.org> - 2024-12-10 10:20 +0100
      Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Richard Lewis <richard.lewis.debian@googlemail.com> - 2024-12-10 14:20 +0100
        Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Julian Gilbey <jdg@debian.org> - 2024-12-11 17:00 +0100
          Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Richard Lewis <richard.lewis.debian@googlemail.com> - 2024-12-12 00:50 +0100
            Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Julian Gilbey <jdg@debian.org> - 2024-12-15 23:50 +0100
  Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Richard Lewis <richard.lewis.debian@googlemail.com> - 2024-12-28 22:20 +0100
  Bug#1089588: chkrootkit: updates access times of /tmp/* and lots more, breaking systemd-tmpfiles Richard Lewis <richard.lewis.debian@googlemail.com> - 2024-12-30 14:20 +0100

csiph-web