at/atq disabled on bolt

[nsr500]

I just found out the hard way (no notice) that at(1) has been permanently disabled on bolt for "security" reasons.

The loss of at/atq in my case broke the main script that manages my fairly simple web site, as it was used to accurately cycle webcam images based on calculated sunrise/sunset.

Given at(1) runs in the same user environment as when logged in to bolt, this makes little obvious sense, and I fail to see how sonic can claim to offer linux shell accounts when fundamentals like at(1) cannot be securely managed.

Perhaps the technical management for shell access should evaluate a longer term strategy and run something a bit more robust than redhat 7.3 and a 2.4.37 kernel instead of crippling fundamental unix work environment tools.

Very disappointing and very un-sonic-like.

Tim.

[nsr500]

Similar to the loss of at/atq, in-place crontab updates appear to be disabled on bolt, and so traditional, scriptable methods for automated, periodic job control are limited. The following does work:

Code: Select all

#!/bin/bash
crontab -l | grep -v '^# ' > crontab.current

# edit crontab.current, save to crontab.new

export EDITOR=ed
crontab -r
crontab -e << EOF
r crontab.new
w
q
EOF

Cheers,
Tim.

[scott]

I just found out the hard way (no notice) that at(1) has been permanently disabled on bolt for "security" reasons.

[...]

Very disappointing and very un-sonic-like.

Tim.

That was my bad, I'm sorry for being un-sonicy.

Actually, the idea was to remove setuid bits from programs owned by "root" _without_ breaking existing functionality. This is the way Bolt has run in the past, but setuid root binaries seem to have crept onto the system over the years.

I put the setuid bit back on for at(1) last night, but I'm not sure what is up with crontab(1), which has always been setgid "crontab". I'll see what's going on with the latter, and make sure we don't cause any more trouble for folks who use at(1).

-Scott

[nsr500]

Thanks Scott, no worries.

I had received this reply from sonic support

User access to the at command has been modified in an effort to improve the security of bolt.sonic.net. I don't know of any plans to fix this at this time. Sorry for the inconvenience.

from which I drew my own conclusions, relieved to hear otherwise.

Seems ssh access to bolt is down at this time, but FYI the crontab update form was that wasn't working was the basic
'crontab <file_name>' method.

Cheers,
Tim.

[scott]

Seems ssh access to bolt is down at this time, but FYI the crontab update form was that wasn't working was the basic
'crontab <file_name>' method.

Cheers,
Tim.

Strange things afoot on Bolt this morning, the out-of-memory killer was active.

However crontab(1) is acting now, it would appear to have been like that since we installed the (setgid) vixie cron 4.1. Having said that, crontab -e works for me and Kelsey, so I'll have to investigate further to figure out why it doesn't work for you.

-Scott

[scott]

Tim,

Not sure what's up -- I su-ed to your account and successfully ran "crontab -e".

Do you have an error message you are seeing?

-Scott

[nsr500]

Might be board posting lag, but here it is again:

$ crontab ./crontab.curr
cannot chdir(/var/cron), bailing out.
/var/cron: Permission denied
_[Sonic:/home/n/nsr500]_

'crontab -e' works.

[scott]

Ah, okay, I had misunderstood.

Will check this out most likely this evening, unless someone else grabs this first...

[casner]

Looks like this situation us unchanged after two years. crontab <file> does not work, but crontab -e does.