BTW the VL6-STD is installed in mini HP 2133 and there is the same problem as withVL6-Light-Live running from CD or installed.Therefore I conclude it is a VL6 issue. I ever, never had that problem and I use command 'at' quite often.

The security hole:Anyone who can use the at command now potentially has access to most files on your machine. If the temp files can be altered, the jobs can be altered. Wouldn't take much knowledge (but more than I have right now) to get daemon to do just about anything it has permissions for.

Suggestions:See if your jobs can be done with cron.Try to build at and friends from a deb package or deb sources. " BSD sources or so.Request a new package of at and mention the problem and "upstream to Slack".

Glad you got to see it work, but I won't be using it this way. Reminds me to do some "un-chmod".

Removed 'at'. When trying to reinstall with gslapt the newly upgraded gslapt -0.5.3c crashed every time clicking on a program. Removed gslapt and reinstalled -0.5.3. Installed 'at' and it is working now asuser.

I tried the same as in my Desktop, that is uninstall 'at' and then reinstall. It did change the owner of /var/spool/atjobs from daemon/bin to daemon/daemon as in my desktop, however, trying to use it I still get "you have no permission to use at".

I'm taking notes on differences between Light and STD. Has this machine had Light on it since the last formatting of / ? When I started, permissions for /var/spool/atjobs/.SEQ were 600 root:root, so daemon couldn't access it. The commands I listed for .SEQ are from the at package's doinstall.sh. They're introduced by

Code:

if [ ! -r var/spool/atjobs/.SEQ ]; then

I wouldn't have the good sense to check this in the first place. But unless I missed something, packages are installed by root; the check should be whether daemon can read the file.