[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[leafnode-list] Re: Cannot update timestamp on /var/spool/news/interesting.groups/...: Operation not permitted



David Aldred <nr@xxxxxxxxxxxxxxxxxxx> writes:

> Just noticed this message repeatedly being thrown up by Leafnode:
>
> Nov 17 23:22:41 main leafnode[25280]: Cannot update timestamp 
> on /var/spool/news/interesting.groups/alt.os.linux.mandrake: Operation not 
> permitted
>
> (various groups are affected)
>
> Looks like a permisions problem - but all files 
> under /var/spool/news/interesting.groups (and the directory itself) have 
> owner 'root', group 'news', and permissions 775.

I should have seen this much earlier. My apologies for missing this.

Given your file ownership situation, leafnode has no permission to set
the mtime (and implicitly ctime) without also setting the atime:

  "Changing time stamps is permitted when: either the process has
   appropriate privileges (Linux: has the CAP_FOWNER capability), or
   the effective user ID equals the user ID of the file, or buf must
   is NULL and the process has write permission to the file." (utime(2))

Leafnode does not have CAP_FOWNER capability, and in your case, the
effective user ID is "news" and the user ID of the file is "root". The
buf argument to utime is nonzero as you've seen in the strace you
provided.

For the interesting.groups files, leafnode disregards the atime, and
uses the mtime and ctime to determine how long ago a group was last
read. When the group is read for the first time, and the corresponding
file is created, mtime and ctime are identical. Then the group is read
for the 2nd and subsequent times, leafnode takes care to leave the mtime
unchanged and only update the ctime. It compares these two time stamps
to determine if timeout_short or timeout_long applies to the group's
subscription.

Is there a particular advantage that you draw from having these files
root-owned rather than news-owned?

If not, chown -R news /var/spool/news/* is the easiest way to fix this.

If there is an advantage, you can (with recent leafnode 1.11.X versions)
ignore the error message, but be aware that timeout_long is ignored as a
consequence of the error and timeout_short applies to all groups. In
this case, it is helpful to raise timeout_short to the same number of
days as timeout_long, to prevent premature unsubscription from the groups.

HTH,

-- 
Matthias Andree
-- 
_______________________________________________
leafnode-list mailing list
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
https://www.dt.e-technik.uni-dortmund.de/mailman/listinfo/leafnode-list
http://leafnode.sourceforge.net/