"atd" can not be started (or dies when started) as soon as it tries to process a "at job" - the error is "Can't link execution file: Permission denied". A strace shows that the problem is with accessing the job file in "/var/cron/atjobs" - which is owned by the original submitter with the permissions of 600.
Created attachment 3583 [details] output of "strace atd -d"
I've now been doing some research and I've found that: - atd is running as user 'at' - the job file, which 'at' executable creates to /var/cron/atjobs/, has permissions 0700 and is owned by the user who issued the at command - atd will die beacuse of this when trying to execute job - atd will die instantly on start, if such a situation exists Is the solution: - to change atd to run as 'root'? - to change 'at' to create the job file to be owned by 'at'? - something else? I don't think atd should die on that permissions error.
Seems fine this side :( nosferatu root # ls -ld /var/cron/at* drwx------ 2 at at 4096 Sep 3 20:46 /var/cron/atjobs drwx------ 2 at at 4096 Sep 3 20:46 /var/cron/atspool nosferatu root # ---------------------------------------------------------------------------- azarah@nosferatu gentoo-src $ at now warning: commands will be executed using /bin/sh at> ls at> <EOT> job 1 at 2002-09-03 20:38 azarah@nosferatu gentoo-src $ mail Mail version 8.1.1-11 6/6/93. Type ? for help. "/var/mail/azarah": 1 message 1 new >N 1 azarah@nosferatu.lan Tue Sep 3 20:38 38/679 "Output from your job 1" & Message 1: From azarah@nosferatu.lan Tue Sep 3 20:38:21 2002 Delivered-To: azarah@nosferatu.lan Subject: Output from your job 1 To: azarah@nosferatu.lan Date: Tue, 3 Sep 2002 20:38:21 +0200 (SAST) From: azarah@nosferatu.lan CVS anaconda_for_gentoo backup cd-tools davoid gaarde gentoo-installer gentoo-web gentoo-xml gentool gentoonewt kernel kernel-janitor keychain libgentoo livecd messenger patches portage portage.test portage2 rc-scripts reflection release sys-tools verwilst & At EOF & q Saved 1 message in mbox azarah@nosferatu gentoo-src $ ----------------------------------------------------------------------- azarah@nosferatu gentoo-src $ at +5minutes warning: commands will be executed using /bin/sh at> ls at> <EOT> job 2 at 2002-09-03 20:46 azarah@nosferatu gentoo-src $su - nosferatu root # ls -l /var/cron/atjobs/ total 4 -rwx------ 1 azarah azarah 3035 Sep 3 20:41 a0000201063786 nosferatu root # exit azarah@nosferatu gentoo-src $ mail Mail version 8.1.1-11 6/6/93. Type ? for help. "/var/mail/azarah": 1 message 1 new >N 1 azarah@nosferatu.lan Tue Sep 3 20:46 38/679 "Output from your job 2" & Message 1: From azarah@nosferatu.lan Tue Sep 3 20:46:00 2002 Delivered-To: azarah@nosferatu.lan Subject: Output from your job 2 To: azarah@nosferatu.lan Date: Tue, 3 Sep 2002 20:46:00 +0200 (SAST) From: azarah@nosferatu.lan CVS anaconda_for_gentoo backup cd-tools davoid gaarde gentoo-installer gentoo-web gentoo-xml gentool gentoonewt kernel kernel-janitor keychain libgentoo livecd messenger patches portage portage.test portage2 rc-scripts reflection release sys-tools verwilst & d* & q azarah@nosferatu gentoo-src $ -----------------------------------------------------------------------------
Something must be different on your system than ours - I just install "sys-apps/at" on a system that did not previously have it and added one job as "root" - and it still exhibits the same problem. Do you have "grsecurity" enabled or not? Is "atd" setuid to root?
nosferatu root # ls -l /usr/sbin/atd -rwxr-xr-x 1 root root 15424 Jul 25 00:07 /usr/sbin/atd nosferatu root # grep at: /etc/passwd at:x:25:25:at:/var/spool/cron/atjobs:/bin/false nosferatu root #
Here is my system: # ls -sla /usr/sbin/atd 16 -rwxr-xr-x 1 root root 15156 Sep 3 15:06 /usr/sbin/atd # grep '^at' /etc/passwd at:x:25:25:at:/var/cron/atjobs:/bin/bash # grep '^at' /etc/group at::25:at # NOCOLOR=yes emerge search at * sys-apps/at Latest version Available: 3.1.8-r8 Latest version Installed: 3.1.8-r8 Homepage: Description: Queues jobs for later execution Base system is gentoo-1.2, kept up-to-date daily with "emerge rsync" and "emerge -u world". Kernel: 2.4.19-crypto-r7 with grsecurity enabled (all the parameters below are set to "1"): altered_pings audit_mount chroot_deny_chdir dmesg fifo_restrictions forkfail_logging grsec_lock linking_restrictions rand_ip_ids rand_pids rand_rpc rand_tcp_src_ports rand_ttl secure_kbmap suid_root_logging
Pretty much the same except for user at's SHELL, and the fact that I am not running grsecurity.
I have Grsecurity compiled in and I have the problem. kernel 2.4.19-gentoo-r7 I have the same version of 'at' as Thomas and everything else seems to be just like you two have. I haven't touched user 'at's SHELL, it's /bin/bash. From kernel .config: CONFIG_GRKERNSEC=y # CONFIG_GRKERNSEC_LOW is not set CONFIG_GRKERNSEC_MID=y # CONFIG_GRKERNSEC_HI is not set # CONFIG_GRKERNSEC_CUSTOM is not set # CONFIG_GRKERNSEC_KMEM is not set # CONFIG_GRKERNSEC_ACL is not set # CONFIG_GRKERNSEC_PROC_ADD is not set # CONFIG_GRKERNSEC_CHROOT_SIG is not set # CONFIG_GRKERNSEC_CHROOT_CHMOD is not set # CONFIG_GRKERNSEC_CHROOT_NICE is not set # CONFIG_GRKERNSEC_PAX is not set # CONFIG_GRKERNSEC_PAX_MPROTECT is not set # CONFIG_GRKERNSEC_MMAPFIXED is not set # CONFIG_GRKERNSEC_CHROOT_PTRACE is not set # CONFIG_GRKERNSEC_AUDIT_PTRACE is not set # CONFIG_GRKERNSEC_AUDIT_MOUNT is not set # CONFIG_GRKERNSEC_PTRACE is not set # CONFIG_GRKERNSEC_PTRACE_GROUP is not set # CONFIG_GRKERNSEC_CHROOT_CAPS is not set CONFIG_GRKERNSEC_FLOODTIME=30 CONFIG_GRKERNSEC_LINK=y CONFIG_GRKERNSEC_FIFO=y CONFIG_GRKERNSEC_FD=y CONFIG_GRKERNSEC_KBMAP=y CONFIG_GRKERNSEC_RANDPID=y CONFIG_GRKERNSEC_EXECVE=y CONFIG_GRKERNSEC_DMESG=y CONFIG_GRKERNSEC_RANDID=y CONFIG_GRKERNSEC_RANDSRC=y CONFIG_GRKERNSEC_RANDRPC=y CONFIG_GRKERNSEC_RANDPING=y CONFIG_GRKERNSEC_FORKFAIL=y CONFIG_GRKERNSEC_TIME=y CONFIG_GRKERNSEC_SIGNAL=y CONFIG_GRKERNSEC_CHROOT=y CONFIG_GRKERNSEC_CHROOT_MOUNT=y CONFIG_GRKERNSEC_CHROOT_DOUBLE=y CONFIG_GRKERNSEC_CHROOT_CHDIR=y CONFIG_GRKERNSEC_CHROOT_MKNOD=y CONFIG_GRKERNSEC_PROC=y CONFIG_GRKERNSEC_PROC_USERGROUP=y CONFIG_GRKERNSEC_PROC_GID=10 CONFIG_GRKERNSEC_PAX_RANDMMAP=y
Ok, jackpot question .. any one of you two want to try this with a vanilla kernel ?
I just rebooted one of my boxes and did not activate "grsecurity" (I use the sysctl interface) - an atd runs as expected without any problem. I will continue testing and find the one parameter in grsecurity that causes atd to fail. Stay tuned.
The mystery is becoming clearer: The grsecurity parameter "linking_restrictions" is the one that causes "atd" to fail. We should make that clear in the kernel compilation document ...
Peit .. think we could add a note to the docs ?
> Peit .. think we could add a note to the docs ? Your turn ;)
Can a warning about grsecurity be added to the docs? According to http://grsecurity.net, gentoo isn't using the latest version of grsecurity. This might fix the problem?
What docs, installation instructions (at the kernel configuration section)?
Bug time-out
