[Bug 251280] New: Over-secure (non-documented) permissions for at(1) and crontab(1) commands
https://bugzilla.novell.com/show_bug.cgi?id=251280 Summary: Over-secure (non-documented) permissions for at(1) and crontab(1) commands Product: openSUSE 10.2 Version: Final Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: Ulrich.Windl@rz.uni-regensburg.de QAContact: qa@suse.de On a system where PERMISSION_SECURITY was set to "secure", a user cannot execute the at(1) command because of a "Permission denied" on /usr/bin/at. The following problems exist: 1) The manual does not document any magic about the "trusted" group /usr/bin/at belongs to. The user can execute /usr/bin/at if he/she is member of that group. 2) Permissions for the "secure" case seem somewhat over-secure if the files "/etc/at.allow" and "/etc/at.deny" are still used for access control: "grep /usr/bin/at /etc/permissions*" basically outputs: /etc/permissions.easy:/usr/bin/at root:trusted 4755 /etc/permissions.paranoid:/usr/bin/at root:trusted 0755 /etc/permissions.secure:/usr/bin/at root:trusted 4750 3) If the user is imported from YP/NIS, it's more difficult to grant access, as the group "trusted" may not exist on the YP/NIS master server (thinking about a multi-OS environment) There's the same problem again for /usr/bin/crontab. I'd prefer allowing the user to use at(1) over seeing some ugly user scripts running sleep(1) in a background process... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=251280 lnussel@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |security-team@suse.de AssignedTo|bnc-team- |lnussel@novell.com |screening@forge.provo.novell| |.com | Status|NEW |ASSIGNED -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=251280 lnussel@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WONTFIX ------- Comment #1 from lnussel@novell.com 2007-03-07 08:14 MST ------- The permissions are just defaults. You can override them in the permissions.local file. I don't know if anyone actually puts users into the trusted group though, it's existence is documented in /etc/permissions.secure where it's use makes most sense. You can add users to the trusted group via the local /etc/group even in a nis environment. I don't know what program you are referring to with sleep(1). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=251280 ------- Comment #2 from Ulrich.Windl@rz.uni-regensburg.de 2007-03-08 01:31 MST ------- Please try to understand this problem: A specific application is to be restarted during non-working hours automatically when no administrator is present. The at(1) command would normally do the job. However the command to restart the application should be done as non-root, and that's the problem: Root cannot schedule a job for a user (the at(1) command lacks option "-u user"; crontab(1) has it), and the user has no permissions as explained. Now the mentioned sleep(1) would be an ugly workaround: When it's 14:00, and you want to start a command at 23:00, you could do a "sleep 32400; command". That's a poor replacement for at(1) that the admin cannot prevent as much as he doesn't want to see it. Therefore I think the at(1) restrictions are overly secure. Likewise un-restricting permissions though perlissions.local seems counter-productive. The defaults should make sense. As long as at(1) lacks "-u user", the "secure" setting is equivalent to having no at(1) command installed, and this just makes the user re-invent the wheel (most likely in less secure ways). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
participants (1)
-
bugzilla_noreply＠novell.com