Bug 468337 - At Refuse to Work with Non-login Shell
At Refuse to Work with Non-login Shell
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: at (Show other bugs)
10
All Linux
high Severity high
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-24 04:01 EDT by CAI Qian
Modified: 2008-12-03 04:31 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-03 04:31:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description CAI Qian 2008-10-24 04:01:41 EDT
Description of problem:
The problem could be demonstrated by the following program running by root.

useradd -m foo
echo foo >/etc/at.allow
cat <<EOF >/home/foo/at
#!/bin/sh
echo "echo bar >/tmp/bar" | at now
EOF
chmod 777 /home/foo/at
su foo -c /home/foo/at
ls -l /tmp/bar

At does not schedule the job, and it is confusing that at does not show any warning or error message. 
ls: cannot access /tmp/bar: No such file or directory

It has the same problem with sudo.

It works with a login shell.
su foo -l -c /home/foo/at

Version-Release number of selected component (if applicable):
at-3.1.10-25.fc10.x86_64

How reproducible:
always

Steps to Reproduce:
See above.
  
Actual results:
ls: cannot access /tmp/bar: No such file or directory

Expected results:
/tmp/bar exists.
Comment 1 Bug Zapper 2008-11-25 23:11:23 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Marcela Mašláňová 2008-12-03 04:31:38 EST
The job is in queue and it is scheduled. In foo's mail you can find failure of job.

The error message is quite abstract, but I suppose this is correct shell behaviour. foo doesn't have environment settings, so it can't run the command. After '-l' is used, than some enviroment variables for user are set.

Note You need to log in before you can comment on or make changes to this bug.