Bug 681979

Summary: users cannot submit jobs with the "at" command
Product: [openSUSE] openSUSE 11.4 Reporter: Ulrich Deiters <ulrich.deiters>
Component: BasesystemAssignee: E-mail List <bnc-team-screening>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: meissner
Version: Factory   
Target Milestone: ---   
Hardware: x86-64   
OS: openSUSE 11.4   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Ulrich Deiters 2011-03-23 15:34:41 UTC 
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12) Gecko/20110222 Firefox/4.0b12

After an upgrade from openSuSE 11.3 to 11.4, the computer reports "no permission" when I try to submit a background job with the at command.

Details: /etc/at.deny exists and is empty.
/etc/at.allow exists and contains some usernames, permission is 644.
atd is running; a restart did not change its behaviour.
Only root can use the "at" command.

Reproducible: Always

Steps to Reproduce:
in a terminal window, enter

at now

Actual Results:  
error message:

/usr/bin/at: Keine Berechtigung (= no permission)

Expected Results:  
should give a warning "commands will be executed under XYZ shell",
then print a prompt: 

at>
Comment 1 Marcus Meissner 2011-03-23 15:57:34 UTC 
your permission setting might be too strict.

ls -la /usr/bin/at

if it shows just -rwxr-x-rx, the setuid bit is not there, and likely removed by
our permission handling.

at only works in "easy" and "secure" poermission mode, not in "paranoid".

grep PERMISSION_SECURITY /etc/sysconfig/security
Comment 2 Ulrich Deiters 2011-03-23 16:48:17 UTC 
ls -la /usr/bin/at ->
-rwsr-x--- 1 root trusted 52360 19. Feb 04:13 /usr/bin/at

This is too restrictive, indeed.

grep PERMISSION_SECURITY /etc/sysconfig/security ->
# PERMISSION_SECURITY. If PERMISSION_SECURITY contains 'secure' or
CHECK_PERMISSIONS="set"
PERMISSION_SECURITY="easy local"

It seems that the upgrade changed the permissions without looking at the security level. After 

chmod o+rx /usr/bin/at

"at" performs normally again. I consider my problem solved, but you should check the permission handling of the upgrade process.

Thank you for your help!
Comment 3 Marcus Meissner 2011-03-24 14:43:13 UTC 
hmm, looks as if the permissions were not applied correctly, they should have for an installation with regular rpm calls. (it is done in %post section via %run_permissions)

Also via SuSEconfig --module permissions

strange, but as you adjusted it, hard to reproduce ;)
(your report seem also the first I see, so it is probably just a random happening)