Arch Linux

cjpembo

Member

Registered: 2008-08-06

Posts: 105

What The FRACK

Just installed Community/minidlna ...

Didn't work.

DO NOT DO THIS !!!!!!!!!!

/etc/rc.d/minidlna clean  <--- DO NOT DO THIS!!!

IT HOSES YOUR ENTIRE MACHINE... FRACK!

Deletes your drive.. hoses GRUB .. Etc

I'm one pissed off IDIOT right now.

Immediately shut off the machine, but it's fubar-ed.  Booted into a live cd to check it out.. and much is gone... including /etc/ directory... so I cant see what the "clean" command did.

If this is someone's idea of an April Fools joke, F.U.

cjpembo

Member

Registered: 2008-08-06

Posts: 105

Re: What The FRACK

Looks like the "clean" option tries to delete the minidlna db as follows:

rm -r $db_dir/*

Of course, $db_dir IS NOT DEFINED BY DEFAULT in /etc/minidlna.conf

So, it is basically just a rm -r /*

Real nice quality control there, guys.  But I guess, ultimately, I'm the idiot who actually ran ./minidlna clean without reading the fine print.  Frack me.

(Irony:  today is National Backup Day)

jakobm

Member

Registered: 2008-03-24

Posts: 132

Re: What The FRACK

/etc/rc.d/minidlna

clean)
  $0 stop
  sleep 1
  stat_busy "Cleaning minidlna cache"
  rm -r $db_dir/*
  stat_done
  sleep 1
  $0 start
  ;;

Bad, if db_dir isn't set in /etc/minidlna.conf (default):

# set this if you would like to specify the directory where you want MiniDLNA to store its database and album art cache
#db_dir=/var/cache/minidlna

Please file a bug, and restore from your well-kept backups.

jelly

Administrator

From: /dev/null

Registered: 2008-06-10

Posts: 716

Re: What The FRACK

http://arch.har-ikkje.net/gfx/rm-rf.jpg

---

dotfiles

ilpianista

Fellow developer

Registered: 2007-10-06

Posts: 568

Website

Re: What The FRACK

Thanks for the notification. I removed it from [community] and reported the bug to the maintainer (FS#23542)

cjpembo

Member

Registered: 2008-08-06

Posts: 105

Re: What The FRACK

So, I suppose rm removes files/directories alphabetically?  Good thing I didn't have all my media and backups mounted in their usual location:

/Archive

My drives are fast; so I lost boot, etc, home and more (horay for ext4 with noatime).  For now on, I think I'll mount my backup drive under /zzzArchive so it would be the last to go if it were mounted???

Is there any way to run daemons with non-root access?  Seems like a much safer way to go.

eldragon

Member

From: Buenos Aires

Registered: 2008-11-18

Posts: 1,029

Re: What The FRACK

http://arch.har-ikkje.net/gfx/rm-rf.jpg

how about

rm -rf /*

?

jelly

Administrator

From: /dev/null

Registered: 2008-06-10

Posts: 716

Re: What The FRACK

http://arch.har-ikkje.net/gfx/rm-rf.jpg

how about

rm -rf /*

?

Yeah,

Well the bug has been fixed

---

dotfiles

tomk

Forum Fellow

From: Ireland

Registered: 2004-07-21

Posts: 9,839

Re: What The FRACK

Is there any way to run daemons with non-root access?  Seems like a much safer way to go.

Of course. Sanely-written daemons will drop privileges by design - others can be run as your user, their own dedicated user, or the 'nobody' user.

cjpembo

Member

Registered: 2008-08-06

Posts: 105

Re: What The FRACK

I don't know if I made it clear in the first post... the minidlna daemon did not function at all (x86_64).  The daemon would fail to start.  I had no problem running the pre-built binary from the minidlna website; my blu-ray set-top-box found the server just fine.  Perhaps the package was never tested before placing it in the community repo?  Only tested on x86 and assumed it would work on x86_64?

eldragon

Member

From: Buenos Aires

Registered: 2008-11-18

Posts: 1,029

Re: What The FRACK

Is there any way to run daemons with non-root access?  Seems like a much safer way to go.

Of course. Sanely-written daemons will drop privileges by design - others can be run as your user, their own dedicated user, or the 'nobody' user.

it wasnt the daemon which hosed the system, but the rc.d script which apparently has to be run as root.

maybe rc.d scripts should drop privileges to whichever user should own the /etc/<daemon> files (which usually is root btw). is there a design flaw? or daemons are too lazy to own their config files?