Bug#265983: libarts1: Do not depend on the jack packages they bring in too much crap
stop Note 1: If this causes the bug to reopen, just reclose it. Note 2: The stop line above is just there in a vane attempt to avoid affecting the bug status, but I forgot where I put the BTS refcard... Note 3: Since sarge is now much closer than it was when the bug was filed, changing libarts (again) at this stage is probably worse than undoing a risky move during the early phase of the freeze. So you may downgrade all the way to wishlist now. --nO3oAMapP4dBpMZi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline tags 265983 + wontfix stop 1. It pulls in less than 1MB of installed packages that you might not already have installed. 2. Many things in Debian haven't reached 1.0 yet. I guess jack is relatively new vs the stone age... It has been in Debian since Dec 23 2001 and has been around since ~ Apr 2001 previously being called AES/LAAGA (aiui). 3.5 years isn't that new. Perhaps you don't like ALSA either since it is relatively new (over 6 years old) and just reached 1.0 in the past ~ 8mo. :) 3. I don't see a problem with #248665. BTW arts will most likely be going away when KDE 4 is released in a few years. It is more than a notification system it is closer to a combination of esd and gstreamer. Just to clarify: 1. The complaint is not that Jack takes up a few MB on the disk. it is more the fact that bringing in Jack adds to the overall system complexity, including the introduction of yet another daemon (actually suid) package that I did not ask for. 2. Of cause Jack is not new. The dependency from ARTS to Jack is new, and thus the inclusion of Jack in a lot of systems that previously ran without it. Historically Jack was installed almost exclusively by audiophiles, musicians etc. 3. #248655 is a long standing bug (originally not from me) that the libjack maintainer has (unilaterally) decided that any user who installs libjack (for any reason) can be presumed to consent to the installation of the jackd package, the use of certain kernel security facilities to speed up Jack if those security facilities happen to be present, etc. The bug log for #248655 shows that the libjack maintainer is extremely arrogant about the importance of his own package and seems unable to wrap his head around the possibility that the dependency system may cause libjack to be installed by people who never asked for it. Given this kind of stubbornness I would recommend that libjack dependencies be avoided like the plague. In one of the responses he sent to me on that bug he even insisted that having things like KDE/ARTS depending on Jack is a misuse of the high and mighty Jack. -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any.
Re: Two Kmail users in one X session
On Thu, Mar 14, 2002 at 02:21:13PM +0200, Jarno Elonen wrote:
...
I'm trying to make a shortcut/script/program that would start Kmail as
another user (and thus open the corresponding mailbox) in my own KDE session
without having to type in the password.
My latest attempt was a 'SUID user2' program in C:
Hinclude unistd.h
int main () {
putenv(HOME=/home/user2);
system(/usr/bin/kmail);
puts(Done.);
}
This apparently doesn't set all the environment variables correctly:
...
Any better ideas on how to implement this?
...
Hi
I am sorry to say, that all the methods proposed on this thread
are quite insecure, as they all allow user1 (and any virus/trojan
programs running as user1) to perform any and all commands as
user2.
rsh, ssh and friends all do this explicitly.
Your fine little program would be ok, if it did several extra steps
(like setruid, setrgid, filtering the environment, etc.).
Personally, I would recommend that you install super and add this
to your super.tab
user2mail /usr/bin/kmail nargs=0 u+g=user2 user1
also do
# ln -s /usr/bin/super /usr/local/bin/user2mail
then user1 can run KMail as user2 by simply running
$ user2mail
super does all the nasty security checks for you, without asking
about passwords etc. The only security hole left is, that you can
probably use the menus in KMail to run programs as user2.
An entirely different option would be if kmail has a command to
open additional mailbox files. Then you could place a line in
/home/user2/.forward which moves all the mail to
/home/user2/mailbox2, which you then grant user1 rw access to.
Happy computing
Jakob
--
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.
pgpr2dM53TXbs.pgp
Description: PGP signature
