Hacker News Reader

Comment by jerf | Hacker News Reader

Asked there, but I'll tack it on here too: What is the purpose of that absurd-seeming restriction on file names? If you can drop arbitrary executables into directories on the file system, you've already "won", so I assume it's not security. I've read the run-parts man page, and that just pushes the problem back one level. If it's just to avoid running old files, that's an absurdly large hammer to hit that problem with.

View on HN

My guess is they wanted to avoid running .dotfiles and #emacsbackup~ files and threw out the baby with the bathwater.

Also '.bak' or '.old'

Isn't ".bak" a fairly logical file extension for a cron job intended to, e.g., perform backups?

Are #emacsbackup~ files executable by default? If not, that's a very weak reason.

(honestly I dunno; have never used EMACS yet)

Well, # is actually used for emacs autosave files (or something else regarding open buffers). Making ~ backups is indeed on by default.

Then again, if you're editing files in /etc/ as root and using emacs to do so, you kinda deserve what you get.

Wait, my intented question was, `do those backup files have the executable permission bits set'? Not `do they hold valid input for interpreter/CPU'.

In Slackware's startup scripts, there's a good bunch of

  if [ -x SOME_FILE ]; then    # if the file is executable, run it
    ./SOME_FILE start
  fi

which makes it trivial to enable/disable various services by simply chmod +x SOME_FILE / chmod -x SOME_FILE. If EMACS' backup files were marked as not executable by the editor, that would be `case closed' for me, no need to pay extra attention to characters in file names.

Yes, backup files have the executable bit set. They have the same bits as the real file.

They are in fact created by renaming the real file to the backup name, then saving the real file and copying the permissions.

According to the summary on the Ubuntu bug: "Essentially, we don't want to allow a '.' because of .dpkg-old and .dpkg-dist files."

Is the implication that you can have .dpkg files in cron folders that you wouldn't want to try to execute?

https://bugs.launchpad.net/ubuntu/+source/debianutils/+bug/3... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=68561

I posted a link (http://news.ycombinator.com/item?id=2701527) to a Debian bug that explains the rationale (aside from the historical behavior argument) a little better: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=308911

My apologies; I must have missed the comments in between my first looking at it and posting my comment.

I have no clue why run-parts does this; but BSD periodic doesn't.

Yes, it's not a bug in Vixie Cron (which I think BSD cron may use) but in the Linux distros (who are responsible for adding run-parts).

.py, .pl, .sh and (as people realize they'are actually writing bash scripts) .bash are standards people actually use. Having them break in what amounts to an include dir is bad mojo.

I can't speak for other BSDs, but FreeBSD's cron is still derived from Vixie cron.

OpenBSD uses Vixie Cron as well.

Reply on news.ycombinator.com