atd fails to start on new kernel 2.6.35-6

> When I start atd I get the following in my syslog:
>
> atd[3840]: Can't link execution file: Operation not permitted
> kernel: [ 9095.373990] deprecated non-accessible hardlink creation was attempted by: atd
>
> and it fails to start. I looked at the Debian changelog for the kernel
> and there was a change regarding apparmor and hardlinks. Do I need to
> have apparmor installed? I removed it because I saw no need for it.

This seems to be caused by [1]. Try

  sysctl -w fs.weak-nonaccess-hardlinks=1

to revert to the old behavior as a workaround.

I wonder if the check for hardlink creation should be relaxed to also
allow linking when the user could delete the file in question.

Regards,
Ansgar

[1] <http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=069cb89e17c6dc5b2a1de2469746bc42935850fb>

 status triaged
 importance high

Gentoo has seen this too: http://bugs.gentoo.org/4268
A possible work-around:
http://shaddack.twibright.com/patches/atd/at-3.1.8-symlinkhack.patch

The work-around isn't valid. The lock file must be a hardlink due to how enqueue/dequeue works, and the nlinks tests. As a result, the simple solution is to just wrap link() in PRIV_START/PRIV_END.

This bug was fixed in the package at - 3.1.12-1ubuntu2

---------------
at (3.1.12-1ubuntu2) maverick; urgency=low

  * Perform queue hardlinks with full privileges (LP: #598824).
 -- Kees Cook <email address hidden> Sun, 27 Jun 2010 12:13:43 -0700

@Tobias, BTW, I would strongly recommend putting AppArmor back -- it protects a number of services including cups, which runs as root still.

On So, 2010-06-27 at 19:36 +0000, Kees Cook wrote:
> @Tobias, BTW, I would strongly recommend putting AppArmor back -- it
> protects a number of services including cups, which runs as root still.

Nor running CUPS either. Don’t have a printer. I like my system slim.
Maybe it will be worth it once I have a beefier system.
Thanks for the fix.

sysctl -w fs.weak-nonaccess-hardlinks=1
error: "fs.weak-nonaccess-hardlinks" is an unknown key

This sysctl was moved:

  sysctl -w kernel.yama.protected_nonaccess_hardlinks=0

Are you still seeing problems? atd should be fixed already.

At least for me this has been fixed since the upload in Comment #4.

I did a:

root@sofa:/etc/sysctl.d# sysctl -w kernel.yama.protected_nonaccess_hardlinks=0
kernel.yama.protected_nonaccess_hardlinks = 0
root@sofa:/etc/sysctl.d#

and in fact - this workaround did it for me.

Is there any backport of 3.1.12 in Lucid available?

@Thomas: were you still seeing the atd bug in current Maverick? atd should be fixed for a while now.

@Kees: I don't have any Maverick installation currently.

This one came up in a from-the-scratch Lucid installation from August 16th using the 2.6.35.19 ppa.

Sep 3 18:40:16 sofa init: atd main process (16523) terminated with status 1
Sep 3 18:40:16 sofa init: atd respawning too fast, stopped
Sep 3 18:40:16 sofa kernel: [37917.532982] non-accessible hardlink creation was attempted by: atd (fsuid 1)
Sep 3 18:40:16 sofa kernel: [37917.534893] non-accessible hardlink creation was attempted by: atd (fsuid 1)

This AT issue seems to be solved for Maverick only:

Ubuntu 10.04 "Lucid Lynx" -> AT Version: 3.1.11-1ubuntu5
Ubuntu 10.10 "Maverick" -> AT Version: 3.1.12-1ubuntu2

So Lucid still contains the older, non patched version of "at" and "atd".
I agree, this problem still exists in Ubuntu 10.04 "Lucid".

Kind regards,
Thorsten

Accepted at into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Works for me on lucid-userspace+maverick kernel, i386. Which is where I first encountered the issue.

This bug was fixed in the package at - 3.1.11-1ubuntu5.1

---------------
at (3.1.11-1ubuntu5.1) lucid-proposed; urgency=low

  * atd.c: perform queue hardlinks with full privileges to stay
    compatible with kernels with hardlink restrictions (LP: #598824).
 -- Kees Cook <email address hidden> Tue, 11 Jan 2011 14:59:16 -0800