Re: review qemplayer
new version 12.6 was uploaded. It is split into 2 packages. http://mentors.debian.net/package/qemplayer ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: review qemplayer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-10 18:06, wbrana wrote: On 7/9/12, wbrana wbr...@gmail.com wrote: I managed temporary to change limits from command line, but I/O priority can't be increased x@debian:~$ mplayer_nice cant set I/O priority MPlayer svn r34540 (Debian), built with gcc-4.7 (C) 2000-2012 MPlayer Team I submitted kernel bug https://bugzilla.kernel.org/show_bug.cgi?id=44371 It seems limits can't be used. I have got reply: CAP_SYS_ADMIN is required to set rt classes btw, why do you need mplayer_nice in the first place? afaiu, qemplayer is an qt frontend to mplayer, and does not need realtime I/O priorities any more than mplayer itself. looking at the code of qemplayer, i also see that the program will indeed work without mplayer_nice installed. so one possibility would be to drop the qemplayer_nice binary from the qemplayer binary package. mplayer_nice could be provided by a separate binary package (hopefully with some non-suid solution) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/9ds8ACgkQkX2Xpv6ydvS0dgCfd/V8bt9ZA0jXMMLbEoYQltHE 3UUAoMqmXPhjhKuUNn85fqbWNPt8xrUM =fBWm -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: review qemplayer
btw, why do you need mplayer_nice in the first place? afaiu, qemplayer is an qt frontend to mplayer, and does not need realtime I/O priorities any more than mplayer itself. mplayer_nice is key feature of qemplayer. Realtime I/O priority for MPlayer is needed when some other application is fully loading hard drive. It prevents empty buffer in MPlayer. Nice -20 ensures that MPlayer always gets needed CPU time if some other application fully loading CPU. mplayer_nice could be provided by a separate binary package I will consider it. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: review qemplayer
On Wed, Jul 11, 2012 at 6:11 PM, wbrana wbr...@gmail.com wrote: btw, why do you need mplayer_nice in the first place? afaiu, qemplayer is an qt frontend to mplayer, and does not need realtime I/O priorities any more than mplayer itself. mplayer_nice is key feature of qemplayer. Realtime I/O priority for MPlayer is needed when some other application is fully loading hard drive. It prevents empty buffer in MPlayer. Why can't this be properly solved in mplayer2/mplayer instead of in some frontend? -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: review qemplayer
On 7/11/12, Reinhard Tartler siret...@gmail.com wrote: On Wed, Jul 11, 2012 at 6:11 PM, wbrana wbr...@gmail.com wrote: mplayer_nice is key feature of qemplayer. Realtime I/O priority for MPlayer is needed when some other application is fully loading hard drive. It prevents empty buffer in MPlayer. Why can't this be properly solved in mplayer2/mplayer instead of in some frontend? Try to ask MPlayer developers. I'm not one of them. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: review qemplayer
On 7/9/12, wbrana wbr...@gmail.com wrote: I managed temporary to change limits from command line, but I/O priority can't be increased x@debian:~$ mplayer_nice cant set I/O priority MPlayer svn r34540 (Debian), built with gcc-4.7 (C) 2000-2012 MPlayer Team I submitted kernel bug https://bugzilla.kernel.org/show_bug.cgi?id=44371 It seems limits can't be used. I have got reply: CAP_SYS_ADMIN is required to set rt classes ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
review qemplayer (was Re: Please review my package)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi. is it possible for you to reply to messages, so threads are kept intact? also it would be nice if you could use a more meaningful subject (my package refer to a number of packages, non of which is qemplayer) On 2012-07-05 22:14, wbrana wrote: That doesn't change that it is a security hazard! Don't run user apps as root! Don't implement super-user features in user apps - implement it separately, and make it optional to use it. I don't run user apps as root. MPlayer is never started as root. by setting the setuid flag, you _are_ running mplayer_nice as root. Here is mplayer_nice source code with comments: [...] this doesn't mean anything. if your application is dropping root priviges as soon as it can, it still _has_ root priviliges at some point. if the binary can be compromised in a critical state, this means that the an attacker can get easy root access to your machine. Google Chrome is also using setuid binary XOrg server is also setuid binary you might want to contact the packagers of google chome and xorg about that (and they most likely will either fix the problem or have a very good explanation why they need setuid) According to http://linux.die.net/man/5/limits.conf it is possible to enable low niceness for all processes started by all/some user(s), but it isn't possible to limit it to mplayer_nice if started by any user so why do you not want to use it? do you think you are granting too much priviliges to all/some user(s) when using pam_limits? if so, please consider: - - why exactly does mplayer_nice need root priviliges? - - setuid'ing your binary grants the application super-user priviliges. among those are realtime-priorities, reading /etc/passwd and the like. setuid'ing grants all those priviliges. - - pam_limits allows you to fine-tune those priviliges on a per-user basis. e.g. you can grant access to realtime-priorities, but not to reading /etc/passwd or to /dev/null'ing your harddisks. - - pam_limits works on a per user (per group) basis. this is the traditional un*x way to handle security. consider an attacker who gains access to your machine as an unpriviliged user (eg. www-data). they can then simpy run /usr/bin/mplayer_nice to gain root access of your machine. with pam_limits, they first need to become a given user/group-member before they can start _any_ application with realtime priorities. this is bad enough, but not as the first scenario. - - check your /etc/security/limits.d/audio.conf chances are high that you already have this file and that it grants members of the audio group enough rights to run your application as you want it to run. i guess that all users interested in running (and supposed to run) mplayer_nice are already in the audio group. - - ... gsdfmrt IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/6g+YACgkQkX2Xpv6ydvQzFgCfe2fdPylxw1yM0LZ0OHeepFVC S/8AoJ83WeVkNWeJuEvozLTe6bU8McvT =YqkY -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
review qemplayer
is it possible for you to reply to messages, so threads are kept intact? also it would be nice if you could use a more meaningful subject (my package refer to a number of packages, non of which is qemplayer) I can't reply to messages because I'm not subscribed to mailing list because I don't want to get so many e-mails. I'm reading it using archives. if your application is dropping root priviges as soon as it can, it still _has_ root priviliges at some point. if the binary can be compromised in a critical state, this means that the an attacker can get easy root access to your machine. How can be that binary compromised? you might want to contact the packagers of google chome and xorg about that (and they most likely will either fix the problem or have a very good explanation why they need setuid) chrome is using chroot and other things, which don't work without setuid xorg also needs to call functions which don't work without setuid chrome and xorg were just example. There are many setuid apps on Linux. xorg and many other apps are running as root all time. It will be much easier to get root access using these apps than mplayer_nice - - pam_limits allows you to fine-tune those priviliges on a per-user basis. e.g. you can grant access to realtime-priorities, but not to reading /etc/passwd or to /dev/null'ing your harddisks. I will consider it. Will qemplayer be included in Debian if I will use pam_limits? is there any specific reason, why you install files into /usr/share/doc/qemplayer/ and /usr/share/doc/qemplayer-12.5/? I don't know why files are installed into /usr/share/doc/qemplayer/. I'm installing into /usr/share/doc/qemplayer-12.5 because this way is used on Gentoo. all this should go into /usr/share/doc/packagename/ I will consider it. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: review qemplayer
On 12-07-09 at 02:37pm, wbrana wrote: is it possible for you to reply to messages, so threads are kept intact? also it would be nice if you could use a more meaningful subject (my package refer to a number of packages, non of which is qemplayer) I can't reply to messages because I'm not subscribed to mailing list because I don't want to get so many e-mails. I'm reading it using archives. This is a team. You need to subscribe to participate in our teamwork. - - pam_limits allows you to fine-tune those priviliges on a per-user basis. e.g. you can grant access to realtime-priorities, but not to reading /etc/passwd or to /dev/null'ing your harddisks. I will consider it. Will qemplayer be included in Debian if I will use pam_limits? We are striving for high quality packaging, not doing silly negotiating. is there any specific reason, why you install files into /usr/share/doc/qemplayer/ and /usr/share/doc/qemplayer-12.5/? I don't know why files are installed into /usr/share/doc/qemplayer/. I'm installing into /usr/share/doc/qemplayer-12.5 because this way is used on Gentoo. This is not Gentoo. This is Debian. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: review qemplayer
I added following lines to /etc/security/limits.conf and rebooted @audio softnice-20 @audio softrtprio unlimited but it doesn't work id uid=1000(x) gid=1000(x) groups=1000(x),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev) nice -n-20 ls nice: cannot set niceness: Permission denied $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 8055 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 8055 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: review qemplayer
I managed temporary to change limits from command line, but I/O priority can't be increased x@debian:~$ su - Password: root@debian:~# ulimit -e unlimited root@debian:~# ulimit -r unlimited root@debian:~# su - x x@debian:~$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) unlimited file size (blocks, -f) unlimited pending signals (-i) 8055 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) unlimited stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 8055 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited x@debian:~$ cat /proc/self/limits Limit Soft Limit Hard Limit Units Max cpu time unlimitedunlimitedseconds Max file size unlimitedunlimitedbytes Max data size unlimitedunlimitedbytes Max stack size8388608 unlimitedbytes Max core file size0unlimitedbytes Max resident set unlimitedunlimitedbytes Max processes 8055 8055 processes Max open files1024 4096 files Max locked memory 6553665536bytes Max address space unlimitedunlimitedbytes Max file locksunlimitedunlimitedlocks Max pending signals 8055 8055 signals Max msgqueue size 819200 819200 bytes Max nice priority unlimitedunlimited Max realtime priority unlimitedunlimited Max realtime timeout unlimitedunlimitedus x@debian:~$ mplayer_nice cant set I/O priority MPlayer svn r34540 (Debian), built with gcc-4.7 (C) 2000-2012 MPlayer Team ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
