freevo init script start freevo as root. Freevo is a media player application and as such it happens to run on a machine over which many people have direct access. Letting freevo run as root may be a security risk since anyone could make file operations with root privileges (freevo may delete files and play every media file on the hd just using gui commands). It would be nice to have an option in /etc/conf.d/freevo to start it as another user to mimimize security risk due to root privileges in accessing the files. I'd also recommend to set a default user "freevo" during installation process and run it as such user by default (if a user wants to run it as root he should but that shouldn't be the default opion IMHO)
I was just messing around with it, and I belive the reason it's not been done yet, is because the default gentoo start-stop scripts don't like starting scripts. It's a feature! :) So i then went ahead and just did a simple su ${FREEVO_USER} -c "/usr/bin/freevo start" i did see the X server starting, but not freevo itself. obviously starting X and then freevo as the freevo user worked without a problem. So I take it it's not tha tsimple yet, I reconn the easiest fix is to wait till portage has some way of starting scripts. I was having a brainfart that maybe a little ugly hack that I saw done with jabberd could work here aswell: bash -c 'start-stop-daemon --start -c ${FREEVO_USER} \ --make-pidfile --pidfile /var/run/freevo.pid \ -q --exec /usr/bin/freevo -fs &>/dev/null' yes, ugly, but it was worth a try. unfortunatly, didn't work. So though I agree with you, it doesn't appear as easy.
I didn't try to start it in X, only in framebuffer. I used su - $USER -c `source /etc/profile;freevo 2>/dev/vc/10` And it did start... Starting it in X should be much simpler because every wm has a way to autostart some command... one has only to select "autologin" in gdm or whatever login manager he use to get the same result as using the freevo initscript
Hum, theoretically the X login managers should start a freevo session while set on autologin. If someone with a freevo-only system can confirm if this is working I'll put whatever instructions as some elog lines in "pkg_postinst()"....
i tried this and it works with gdm: [Desktop Entry] Encoding=UTF-8 Name=FREEVO Comment=Use this session to run freevo Exec=/usr/bin/freevo Icon= Type=Application
ok, now I know I can "inject" a freevo.desktop in the right place for kdm with : cat /usr/kde/3.5/share/config/kdm/kdmrc | grep ^SessionsDirs= | cut -d = -f 2 cause in kdmrc file the uncommented SessionsDirs=/usr/path points me to the right directory. Is for gdm this folder fixed to /etc/X11/gdm/Sessions/ , or can anyone point me to which file contains the definition and with which syntax? If anyone is so kind to explain/point me a link to the right page for also other login managers (with autologin) that I don't have,things will be faster.
in /etc/X11/gdm/factory-gdm.conf default paths are fixed to SessionDesktopDir=/etc/X11/sessions/:/etc/X11/dm/Sessions/:/usr/share/gdm/BuiltInSessions/:/usr/share/xsessions/ I never used any other login manager so I really can't speak about them. I can olny point out that most wm ebuilds should create all files needed for all login managers so looking at one of them (this is from windowmaker ebuild) may be helpful: src_install() { ................. ................. # create wmaker session shell script echo "#!/bin/bash" > wmaker echo "/usr/bin/wmaker" >> wmaker exeinto /etc/X11/Sessions/ doexe wmaker insinto /etc/X11/dm/Sessions doins ${FILESDIR}/wmaker.desktop make_desktop_entry /usr/bin/wmaker }
Created attachment 99820 [details] freevoboot We're near... I radically modified the initscript to be a kind of a wrapper. It should be run instead of /usr/bin/freevo (put "/usr/bin/freevoboot startx") in freevo.desktop session, and it would also start recordserver/webserver according to /etc/conf.d/freevo . For non-X users it should be run immediately after boot, probably putting: su - $USER -c `source /etc/profile;freevoboot 2>/dev/vc/10` at the end of your /etc/conf.d/local.start Please test. Note that X users don't use daemon, if I understood well,correct me if I'm wrong.
I don't think that using local.start for freevo is good... Local.start is typically used by every runlevel while a user could choose to run freevo only on a particular runlevel. Also stopping and restarting freevo is more pratical with an initscript... I'd leave the initscript for framebuffer users while I'd use autologin for X users IMHO
I tried su - $USER -c `source /etc/profile;freevoboot 2>/dev/vc/10` in local.start but for a strange reason it gives at boot: pygame.error: Unable to open a console terminal while if run from the console (typing /etc/init.d/local stop/start) it works (even if sometimes the screen is shifted higher than usual)
Created attachment 99880 [details] freevo.rc6 (please read below) Ok, we could be near, I tried to modify the initscript to run as freevouser, where freevouser is got from /etc/conf.d/freevo as a line: freevouser="nameofunprivilegedusertorunfreevo" Someone should test this modifying /etc/conf.d/freevo with above line and using the attachment as initscript. BE WARNED: I tried a "trick" to make freevo process run just after local , so it may not work and you might need to reboot from cd/usb or with another profile to restore previous settings (backup /etc/init.d/freevo !)
Created attachment 99881 [details] freevo.rc6 More sane and less risky I removed the risky trick. You still need to use it as /etc/init.d/freevo and to add freevouser="......." to /etc/conf.d/freevo
heavensdoor ~ # depscan.sh -u * Caching service dependencies ... * Services 'freevo' and 'local' have circular * dependency of type 'iafter'; continuing... [ ok ] seems that they have a conflict. I solved this way: depend() { use `ls /etc/init.d/ |cut -d"." -f1|grep -v freevo|grep -v local` } and it starts just before locat (should be sufficent to give time to the console to show up before freevo starts)
sorry I posted just a moment after you
few comments: su - ${freevouser} -c `source /etc/profile;/usr/bin/freevo daemon start` should be: /bin/su - ${freevouser} -c 'source /etc/profile;/usr/bin/freevo daemon start' /bin/su instead of su (in case someone, like me, had set aliases like su="su -") "'" instead of "`" since it doesn't work with the second it gives me: heremitpurple ~ # Could not open logfile: /tmp/freevo/main-1000.log Could not open logfile: /tmp/freevo/main-1000.log Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/freevo/main.py", line 131, in ? import menu # The menu widget class File "/usr/lib/python2.4/site-packages/freevo/menu.py", line 48, in ? import skin File "/usr/lib/python2.4/site-packages/freevo/skin.py", line 98, in ? get_singleton() File "/usr/lib/python2.4/site-packages/freevo/skin.py", line 79, in get_singleton exec('import skins.' + config.SKIN_MODULE + '.' + config.SKIN_MODULE + \ File "<string>", line 1, in ? File "/usr/lib/python2.4/site-packages/freevo/skins/main/main.py", line 51, in ? from area import Skin_Area File "/usr/lib/python2.4/site-packages/freevo/skins/main/area.py", line 67, in ? import xml_skin File "/usr/lib/python2.4/site-packages/freevo/skins/main/xml_skin.py", line 54, in ? osd = osd.get_singleton() File "/usr/lib/python2.4/site-packages/freevo/osd.py", line 149, in get_singleton _singleton = OSD() File "/usr/lib/python2.4/site-packages/freevo/osd.py", line 382, in __init__ pygame.display.init() pygame.error: Unable to open a console terminal
For the temp logfile check that its folder has "other" read permissions (fix with chmod a+rw /tmp/freevo ; chmod a+rw /tmp/freevo/main-1000.log ). The "pygame.error: Unable to open a console terminal" is probably because freevo shouldn't be started before local..... it should be started from something like .bashrc but only for tty0 (so you could still use console on others vt). Do you think this could fix and would be pratical? The only issue being you would need mingetty or some work to autologin..... To check the others, try to login in console as normal user and launch freevo, if they are still there then they're probably due to have run freevo as root and having the cache files or other things written with root-only permissions.
I tried to start the initscript from console so this is not a "start before local" issue. I posted those errors but only one is relevant: pygame.error: Unable to open a console terminal and I think this could be not fixed without some sort of console autologin (something like mingetty should work) or some obscure script magick that I'm not aware of. I fear that there is no pratical way to start freevo at boot time as unprivileged user. At least there is a fix for the X option :-)
The suggested way to run freevo was mingetty, see: http://freevo.sourceforge.net/cgi-bin/doc/BootFreevo We had an initscript cause no-one pointed out that's a potential security risk. For the "pygame cannot open a console terminal error", does it appears if, as normal user in console, you run freevo? If so, it's just matter of cleaning privileges (you ran it as root and it created files as root, some of them without permissions for normal users).
No that problem doesn't show up if I run freevo as a unprivileged user. I think that if it's not run from a console it can't start or execute some internal script. I'll investigate when I have time but as now I have no real clue about this problem.
Created attachment 99908 [details] script to start X automatically without login manager An alternative way to start directly in freevo (in X) could be this. (see attachment) This starts directly X so one could put "/usr/bin/freevo" in .xinitrc or substitute "/usr/bin/freevo" to the startx command inside this script... well maybe is simpler to do this using the autologin function of a login manager but still could be usefull to someone. This script works flawlessly to me
Ouch, we forgot to try to peek at mythtv solution.... it wasnt so difficult to run something after login, for non-x users: einfo "Want Freevo to start automatically? Run the following:" einfo "crontab -e -u freevouser" einfo "where freevouser is the user to run freevo" einfo "Add add the following:" einfo "* * * * * /usr/bin/freevoboot &"
Sorry I got the same error as before. I think that freevo, as unprivileged user in framebuffer, can only be run as root OR with a console command (given from an open console). Maybe mingetty is the only way to make it work. (a note should be made at the end of the ebuild stating that running freevo in framebuffer mode could be a security problem and a link to http://freevo.sourceforge.net/cgi-bin/doc/BootFreevo)
I'm sorry but now that this issue is public we cannot let this ebuild mess users systems. I think I'll give the link at: http://freevo.sourceforge.net/cgi-bin/doc/BootFreevo in the ebuild warnings letting the users configure their preferred start system all alone. You'll need to add: case "`tty`" in /dev/tty1) clear && freevo &>/dev/null;; esac (for getty or mingetty system) at the end of your USER .bash_profile
Really sorry but the only alternatives are masking freevo or making it build only with X flag on....
I don't think this is a security bug of freevo... simply it can run as an unprivileged user in X or as root in framebuffer. The user who choose to run it as root takes its risks and should be made aware of it... masking freevo seems exagerated to me. An ewarn is sufficent IMHO. Alternatively you can remove X use flag (activated by defalut) and ads a "framebuffer" use flag that a user could set to install it without X dependancies (with a warning).
Note that this issue is present only if a user wish to boot directly in freevo in framebuffer... The simplest solution is to remove the initscript and let the user boot directly into it with gdm/kdm autologin. This removes the security risk. Freevo can still be run from console as unprivileged user... to boot directly into it we could put a link to the wiki.
the last solution also solves bug #145289 (no more initscript no more problems ;-) )
Removed the initscript, added notes with 2 links (one to freevo wiki to autostart freevo in user console and one to create a login program for getty) for non-X users, keeped freevoboot and freevo.desktop session for X users (with notes). In both cases initscript is not deleted automatically but a warning is displayed if it's present. (so users can still choose between security risk and zero-efforts autoload). This however means that I'll not consider this update as a security "high priority" bug and I'll post stabilizing request only after one month without bugreports. In cvs as freevo-1.5.4-r1.ebuild
Should be fixed, please note I did all the possible efforts to let one easier way to autoboot to non-X users. This was all what was possible, better luck with freevo-1.6 early in november, I hope.
good, it works to me :-)
I'm very happy that someone is finally trying to fix this. Some criticisms, though: 1) The postinst message has such bad grammar and spelling that it's hardly understandable. 2) /usr/bin/freevoboot is not installed by the ebuild! with regards to the script itself (left lonely in files/): 3) what makes you think I want to stop the recordserver/webserver at the same time as the frontent? The frontend can crash a lot and need restarting, but the webserver and recordserver usually should just keep running. The separation between the two should be kept clearer in the startup scripts. 4) Why should we rely on GDM or KDM for auto-login? That's a lot of extra crap to install for a freevo-only machine. It also means that re-starting freevo might be tied up with re-starting /etc/init.d/xdm, which the freevo user may not be able to control.
1 and 2) My fault, sorry, corrected all what I could in 1.5.4-r2 3) You can always keep /etc/conf.d/freevo with all no and start recordserver and webserver manually, if you need (although I never had a crash..... only issue I found there was recordserver lefting a nasty file when killed.) 4) Ehm... you can use anything you want to autologin, that's just for X users, if you use fb you can still emerge without X flag and you'll save a lot of space, using only fb. I just provided one way for that (combined with options like delay is really flexible), that's the default way also for mythtv. ( http://gentoo-wiki.com/HOWTO_Setup_MythTV#KDM ).
You can also use mingetty for X. einfo is a little unclear about that and seems to suggest you have to use a *dm.
I was looking at the wiki mentioned in the ebuild (with USE=-X) and I think this can cause additional problems. If you use tty1 as described, freevo will also start in single user mode. Instead it would be safer to use anything except tty1. I've setup my box like this: /etc/inittab: c6:2345:respawn:/sbin/mingetty --autologin freevo tty6 /home/freevo/.bash_profile: case "`tty`" in /dev/tty6) clear && /usr/bin/freevoboot xstartx &>/dev/null;; esac This keeps single user mode safe. Keeps tty1-tty5 open for normal usage Logs user freevo in on tty6 and starts freevo in x11 mode.
