http://bugzilla.novell.com/show_bug.cgi?id=550021 User meissner@novell.com added comment http://bugzilla.novell.com/show_bug.cgi?id=550021#c1 --- Comment #1 from Marcus Meissner 2009-10-26 04:36:39 MDT --- osc co Base:System cdrtools -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=550021 Juergen Weigert changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |551319 -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=550021 http://bugzilla.novell.com/show_bug.cgi?id=550021#c4 --- Comment #4 from Henning Paul 2010-01-05 11:51:50 UTC --- home:hennichodernich:branches:Base:System/cdrecord builds for openSUSE_11.2, but not for openSUSE_Factory. The rpmlint suid root exemption for the "easy permissions" case obviously has to be reinstated for openSUSE Factory, since previous exemption must have been transferred to the openSUSE 11.2 config. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=550021 http://bugzilla.novell.com/show_bug.cgi?id=550021#c6 Marcus Meissner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO CC| |dmueller@novell.com Info Provider| |lnussel@novell.com --- Comment #6 from Marcus Meissner 2010-01-05 15:35:09 UTC --- The new limits that make it fail have been added after the new rpmlint... not sure if intentional. Ludwig? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=550021 http://bugzilla.novell.com/show_bug.cgi?id=550021#c8 Marcus Meissner changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |meissner@novell.com --- Comment #8 from Marcus Meissner 2010-06-09 13:51:45 UTC --- Joerg, sorry we lost track on this bug a bit... What feature is that, I can only speculate... - Device Access is there... (with ACLs) - Is it realtime support? THere meanwhile is "rtkit" which could offer this to non-root processes. - Is it some linux kernel specific handling different between root and non root? Can you please elaborate? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=550021 http://bugzilla.novell.com/show_bug.cgi?id=550021#c10 --- Comment #10 from Juergen Weigert 2010-06-09 18:03:55 UTC --- In an earlier report, Joerg described the issue like this:

The Linux kernel maintainers are unwilling to provide an orthogonal way of sending SCSI commands to any type of device that "speaks" SCSI in a single address space. [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310689#42]

I understand that the suid root is needed only as a workaround, so that cdrecord can do things, that should be done within the kernel. I don't remember the details, but I am certain Joerg explained them to me already. Sorry. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c12 --- Comment #12 from Jörg Schiling 2011-02-16 16:52:41 UTC --- Why is this "bug" still open although it has been resolved 7 months ago? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c14 --- Comment #14 from Marcus Meissner 2011-02-16 17:05:46 UTC --- we lost sight of it. SG_SCSI_RESET seems to be the only command requiring root privileges that is called from libscg/scsi-linux-sg.c. we could perhaps talk with the upstream developers to get that allowed or at least find the reasoining why they block it. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c18 Juergen Weigert changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |joerg.schilling@fokus.fraun | |hofer.de --- Comment #18 from Juergen Weigert 2011-02-22 17:42:29 UTC --- Comments like 'There are a lot more things' and 'could be configured in a way that would allow' give hope that a non-suid solution is possible. Details welcome. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c21 --- Comment #21 from Marcus Meissner 2011-02-23 08:18:58 UTC --- What privileges are required and why are they required? Only SG_IO in libscg asks for root privileges, but I do not see why it does. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c23 Thomas Biege changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|joerg.schilling@fokus.fraun | |hofer.de | --- Comment #23 from Thomas Biege 2011-08-05 11:57:37 UTC --- AFAICS needinfo was provided by Joerg. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c25 --- Comment #25 from Jörg Schiling 2012-11-26 10:47:36 UTC --- Sorry, but this is not a bazar, I don't care what privileges you give to "wodim" - it does not work anyway... the correct set of fine grained privileges to get fully functional cdtrtools is documented in the code. As you did not read the code, let me repeat the Solaris privileges: cdrecord: PRIV_FILE_DAC_READ PRIV_PROC_LOCK_MEMORY PRIV_PROC_PRIOCNTL PRIV_NET_PRIVADDR PRIV_SYS_DEVICES cdda2wav: PRIV_FILE_DAC_READ PRIV_PROC_PRIOCNTL PRIV_NET_PRIVADDR PRIV_SYS_DEVICES readcd: PRIV_FILE_DAC_READ PRIV_NET_PRIVADDR PRIV_SYS_DEVICES maybe that PRIV_SYS_DEVICES can be substituted by CAP_SYS_RAWIO on Linux. The rest should be 1:1 ...and as mentioned before: SuSe Linux does not permit to gain these privileges without first becomming root. As long as Linux doees not by default offer the infrastructure for fine grained privilege management, it is obvious that we need to install the named programs suid root. If you like to change that, you are welcome! But this needs a bigger change in Linux first..... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c27 --- Comment #27 from Jörg Schiling 2012-11-26 11:58:13 UTC --- Previous Solaris implementations did require to run a suid root program called "/usr/bin/pfexec" and in 2006, cdrtools have been started via a shell script that called e.g.: pfexec "`dirname $0`/`basename $0`.bin" "$@" but this was a hack. So I mentioned at that time already that it would be better to have an in-kernel pfexec implementation. Since April 2010, an in-kernel pfexec is available and cdrtools manage to get the required privileges completely without ever being root. On Linux this all is not possible. Once Linux offers comparable features in a way that cannot be uninstalled by a user, we could adopt cdrtools to use that, but for now there is no way except for installing the files cdrecord, cdda2wav and readcd suid root. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c29 --- Comment #29 from Jörg Schiling 2012-11-26 17:35:06 UTC --- libscg is a generic SCSI transport library that exists since August 1986. It is the oldest known generic SCSI interface that allows to send _any_ SCSI command to _any_ type of SCSI device. Thinking about terms of "CD devices" at this level is a mistake. Cdrecord and other programs (like e.g. sformat) call libscg to find devices with matching properties for the specifics of the upper layer program. sformat looks for different devices than cdrecord, but using the same low level code in libscg. Even cdrecord looks for more than just devices that the linux kernel knows to be "CD type devices". Libscg also needs to map SCSI type addresses to the non-orthogonal driver interface set on Linux that even provides more than one single driver per device. libscg decides which of the available and usable devices is the best for the operation based on heuristics. On Solaris, the privileges PRIV_FILE_DAC_READ and PRIV_SYS_DEVICES are needed to open and use the needed devices to send all SCSI needed commands to all devices of interest. For Linux SG_IO, PRIV_FILE_DAC_WRITE would also be needed. "Nothing of this seems relevant to cdrecord." is wrong here, the right set of privileges on Linux would be the set that allows "cdrecord -scanbus" to list _all_ SCSI devices - even those that people would not call CD type devices. In addition, the permission to send _any_ kind of SCSI command to an open fd is needed.... cdrecord sends a lot of vendor unique SCSI commands that only cdrecord can identify as "safe for this device". The Linux kernel is far too dumb to do this and the fact that the Linux kernel uses a SCSI command filter list requires cdrecord to be able to tell the linux kernel to ignore this filter list. BTW: On Solaris, the program "truss" lists the missing privileges in case of failing syscalls, e.g.: open64("/dev/rdsk/c0d0p0", O_RDONLY) Err#13 EACCES [file_dac_read] On Linux, there is a port from a truss clone called "strace" (strace was written for SunOS in 1988). I am not sure whether there is a similar feature on Linux. But the main problem is still: Linux is missing a user interface that would allow to gain specific privileges without becomming root. So discussing the list of privileges only seems to be of theoretical interest. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c31 --- Comment #31 from Marcus Meissner 2012-12-04 16:32:14 UTC --- I was foremost trying to understand the requirements (and to write them down). So far most the requirements I see are only required for uninterrupted burning, there is nothing inherent required to burn at all. None of above seems necessary if you consider that modern burners have burnproof(tm) or similar technologies. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c Dirk Mueller changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|dmueller@suse.com |security-team@suse.de -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c34 --- Comment #34 from Jörg Schiling 2013-03-11 13:00:01 UTC --- Is there no actvity at SuSE anymore or is SuSE missing aperson with the needed skills? We are waiting 3.5 years now for a simple thing, this is not acceptable. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c36 Thomas Biege changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #36 from Thomas Biege 2013-04-08 23:22:12 CEST --- No setuid bit for cdrecord. If there is any new solution that needs a review, please open a new bug. Thanks Jan for the hint. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c38 --- Comment #38 from Jörg Schiling 2013-04-12 14:11:03 UTC --- BTW: the current state is "resolved" which would imply that cdrecord is shipped with suid root on Suse already... What is the real state? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c40 Jörg Schiling changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #40 from Jörg Schiling 2013-04-12 14:56:29 UTC --- OK, then this bug needs to be reopened. Also note that fi you like to use fine grained privileges, cdrtools need to be enhanced to know how to get rid of certain privilages later. The related code code suid root and privileges(5) is already in. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c42 Jan Engelhardt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO InfoProvider| |joerg.schilling@fokus.fraun | |hofer.de --- Comment #42 from Jan Engelhardt 2013-04-13 03:25:11 CEST --- Please see attachment #535071 on how program code can drop capabilities to use this for cdrtools. The setcap(8) program is shipped in the "libcap-progs" in openSUSE, "libcap" in other some distros like Fedora; per the manpage, the fscaps feature depends on Linux >= 2.6.24. Without fscaps, only the classic suid bit gets the program enough starting privileges. Dropping privileges by way of setuid() is no longer needed if privs are dropped by way of dropping (all) caps. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c44 --- Comment #44 from Jörg Schiling 2013-04-16 12:14:23 UTC --- You could help a lot if you did find the related equivalent privileges for the following privs from OpenSolaris: PRIV_FILE_DAC_READ any local "file" can be read (needed to open /dev/sg or similar) PRIV_FILE_DAC_WRITE any local "file" can be written (needed to open /dev/sg or similar) PRIV_SYS_DEVICES allow special device specific calls that use additional privileges. Needed to be able to send _any_ SCSI command to any device. This is needed in addition to be able to open(2) device nodes. PRIV_PROC_LOCK_MEMORY allow to lock any current and future (to be allocated) memory in core. On Linux this may need additional privs related to setrlimit(2). PRIV_PROC_PRIOCNTL allow to enhance process scheduling priority to any value PRIV_NET_PRIVADDR allow to bind to sockets with a port number < 1024. Solaris distincts between "effective", "permitted" and "inheritable" privs. Is this also true for Linux? Is the fcaps feature valid for all filesystem types and is it always part of the most limited install variant? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c46 --- Comment #46 from Jörg Schiling 2013-04-17 09:45:00 UTC --- Let me give a short feedback now: 1) SuSE deliveres defective system include files that prevent to compile software (like star) that supports linux (ext* specific) file flags: checking for sched_yield... yes checking for nanosleep... yes checking for /dev/tty... yes checking for /dev/null... yes checking for /dev/zero... yes checking for /dev/stdin... yes checking for /dev/stdout... yes checking for /dev/stderr... yes checking for /dev/fd/0... yes checking for /dev/fd/1... yes checking for /dev/fd/2... yes checking if Linux include file linux/ext2_fs.h is broken... yes checking if Linux include file /usr/src/linux/include/linux/ext2_fs.h is broken... yes checking if Linux include file scsi/scsi.h is broken... no checking if Linux include file /usr/src/linux/include/scsi/scsi.h is broken... no checking if Linux include file scsi/sg.h is broken... no checking if Linux include file /usr/src/linux/include/scsi/sg.h is broken... no Warning: *** /usr/src/linux/include contains broken include files *** Warning: *** /usr/src/linux/include is not used this reason *** Warning: This may result in the inability to use recent Linux kernel interfaces Warning: *** linux/ext2_fs.h is not usable at all *** Warning: *** This makes it impossible to support Linux file flags *** 2) the sample program from the attachment does not compile. This is another result from the defects in /usr/include. In spacial: /usr/include/sys/capabilities.h does not exist. 3) There is no support for capabilities in Suse by default. Isn't it a pity that a system that installs a 6.4 GB sized system does not include 44kBytes of security related software that is needed to avoid suid root binaries? 4) I experimented with the following set: /sbin/getcap cdrecord cdrord = cap_dac_override,cap_net_bind_service,cap_ipc_lock,cap_sys_admin,cap_sys_nice,cap_sys_resource+ep Comments? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c48 Michal Hrusecky changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mhrusecky@suse.com --- Comment #48 from Michal Hrusecky 2013-04-17 10:53:22 UTC --- (In reply to comment #46)

Let me give a short feedback now:

1) SuSE deliveres defective system include files that prevent to compile software (like star) that supports linux (ext* specific) file flags:

checking for sched_yield... yes checking for nanosleep... yes checking for /dev/tty... yes checking for /dev/null... yes checking for /dev/zero... yes checking for /dev/stdin... yes checking for /dev/stdout... yes checking for /dev/stderr... yes checking for /dev/fd/0... yes checking for /dev/fd/1... yes checking for /dev/fd/2... yes checking if Linux include file linux/ext2_fs.h is broken... yes checking if Linux include file /usr/src/linux/include/linux/ext2_fs.h is broken... yes checking if Linux include file scsi/scsi.h is broken... no checking if Linux include file /usr/src/linux/include/scsi/scsi.h is broken... no checking if Linux include file scsi/sg.h is broken... no checking if Linux include file /usr/src/linux/include/scsi/sg.h is broken... no

Warning: *** /usr/src/linux/include contains broken include files *** Warning: *** /usr/src/linux/include is not used this reason *** Warning: This may result in the inability to use recent Linux kernel interfaces

Warning: *** linux/ext2_fs.h is not usable at all *** Warning: *** This makes it impossible to support Linux file flags ***

No URL to the software (try googling star ;-) ), nothing indicates what is broken about that. If you want some help, providing some basic info can help ;-)

2) the sample program from the attachment does not compile. This is another result from the defects in /usr/include. In spacial: /usr/include/sys/capabilities.h does not exist.

$ rpm -ql libcap-devel | grep include /usr/include/sys/capability.h

3) There is no support for capabilities in Suse by default. Isn't it a pity that a system that installs a 6.4 GB sized system does not include 44kBytes of security related software that is needed to avoid suid root binaries?

I got setcap and getcap without installing them explicitly so either they are part of minimal X or quite basic stuff depends on it...

4) I experimented with the following set:

/sbin/getcap cdrecord cdrord = cap_dac_override,cap_net_bind_service,cap_ipc_lock,cap_sys_admin,cap_sys_nice,cap_sys_resource+ep

Comments?

Just a few comments to help you provide more information for people that are working on it - general bugzilla recommendation, I'm just a curious bystander. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c50 --- Comment #50 from Jan Engelhardt 2013-04-17 13:15:44 CEST --- (In reply to comment #46)

Warning: *** linux/ext2_fs.h is not usable at all *** Warning: *** This makes it impossible to support Linux file flags ***

The file does not exist. What were you hoping to find in it? Linux kernel commit 36695673b012096228ebdc1b39a6a5850daa474e promoted the extfs-specific flags to become general filesystem flags, from a programming point of view. For example, EXT2_IMMUTABLE_FL is now FS_IMMUTABLE_FL. See linux/fs.h.

2) the sample program from the attachment does not compile. This is another result from the defects in /usr/include. In spacial: /usr/include/sys/capabilities.h does not exist.

Needs -lcap / libcap.so, available from libcap-devel.

3) There is no support for capabilities in Suse by default.

Capability support is there. It just that it is not *used* in SUSE at this time like it is in Fedora.

4) I experimented with the following set:

/sbin/getcap cdrecord cdrord = cap_dac_override,cap_net_bind_service,cap_ipc_lock,cap_sys_admin,cap_sys_nice,cap_sys_resource+ep

Did it work, at least a bit? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c52 --- Comment #52 from Jörg Schiling 2013-04-17 11:30:49 UTC --- "star" is the first free TAR implementation and the only one that supports Linux specific features. It should be well known by Linux people. The problems in the Linux kernel include files have been discussed since 2004. There is even a project that is intended to suppy fixed linux system include files which is needed as the Linux kernel developers do not like to do their homework. Try to google for that problem.... I meanwhile discovered libcap-devel, but: I am used to work on a OpenSource polatform (OpenSolaris) and for this reason, I expect that after I installed a compiler, I have a working development environment. Unless SuSe is a closed source shop, I would call this a Suse packaging bug that should be fixed to avoid confusion. I installed the default set of packages + compiler and no *cap program was available. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c54 --- Comment #54 from Jörg Schiling 2013-04-17 11:40:55 UTC --- cdrecord was basically usable with this set of flags, but I would need to test all features to be sure. The comment in linux/capability.h lead to CAP_SYS_ADMIN as a prerequisite for being able to send any SCSI command. Do I need CAP_SYS_RAWIO in addition? In special the capability of being able to send any SCSI command only hits when speficic vendor unique commands are needed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c56 --- Comment #56 from Marcus Meissner 2013-04-17 11:50:23 UTC --- All your tools will work just fine without any setuid root bits or capabilities. /dev/sg* is writeable and so usable by the regular desktop user due to ACLs being handed to it via udev. As wodim and other cd accessing tools live happily without any setuid bits or capabilities, you will have to convince us why you need them first. (I still do not see the need of any special privileges for cdrecord and friends at this time.) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c58 --- Comment #58 from Jan Engelhardt 2013-04-17 14:01:37 CEST --- (In reply to comment #53)

If there was another incompatible interface change in the linux kernel, I was assuming that the related developers at least inform the users of the code.

Ok, this does not seem to have happened. But I wager to say that ext2 attrs is not something that has been used very much, even within extfs. What does cdrtools use the flags for? grep -r '_FL\b' or grep -r '\bEXT2_' in the cdrtools-3.01a12 source does not yield any result. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c60 --- Comment #60 from Jörg Schiling 2013-04-17 12:05:28 UTC --- (In reply to comment #58)

(In reply to comment #53)

Ok, this does not seem to have happened. But I wager to say that ext2 attrs is not something that has been used very much, even within extfs.

What does cdrtools use the flags for? grep -r '_FL\b' or grep -r '\bEXT2_' in the cdrtools-3.01a12 source does not yield any result.

Well, if I start compiling on a new or otherwise empty platform, I always start to compile ftp://ftp.berlios.de/pub/schily as this e.g also contains a smake bootstrap. Also the Schily Makefilesystem is project independent, so it contains autoconf tests for anything you may need. The file flags are in use by star that is able to archive and restore them. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c62 --- Comment #62 from Jan Engelhardt 2013-04-17 14:10:52 CEST --- (In reply to comment #60)

The file flags are in use by star that is able to archive and restore them.

As the flag name change is now in the past, you will have to bite the bullet. To the best of my judgment, the Linux header files do not have any stability guarantees; the only guarantee is that the system calls continue to work if you have a compiled program. Then, to keep programs compiling in both old and new environments, programs like iptables — and even e2fsprogs — choose to ship a copy of the header file(s) that they use. Maybe you want to do the same for ext2_fs.h for star/smake. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c64 --- Comment #64 from Jan Engelhardt 2013-04-17 14:22:29 CEST ---

(In reply to comment #55)

Did you also check layered transports like *ATA and USB? There is ATAPI and USB mass storage encapsulation, that may apply filters.

I have not checked yet; I would assume that, since permission checks make most sense at the user boundary (i.e. in the ioctl function) that there are no extra restrictions during encapsulation. Can you name a vendor-specific ioctl you are issuing, and where it occurs in cdrtools? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c66 --- Comment #66 from Jörg Schiling 2013-04-17 17:45:44 UTC --- Regarding ext2fs.h: I just discovered, that star already first looks for ext2fs/ext2_fs.h It seems that I just need to disable the related warning from "configure". Thank you for your hint! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c68 --- Comment #68 from Jörg Schiling 2013-04-22 16:49:08 UTC --- The final version for cdrtools-3.01a14 has been published at: ftp://ftp.berlios.de/pub/cdrecord/alpha/ The testversion has been removed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c70 --- Comment #70 from Dave Plater 2013-05-03 11:28:15 UTC --- (In reply to comment #69) It seems that Jörg is under the impression that he has complied in comment 67 and in his mail to me. The only program that's setuid is /usr/bin/cdrecord the equivalent of /usr/bin/wodim also setuid. Are the three files in /etc/permissions.d the problem? Should we rather use the wodim method? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c72 Marcus Meissner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|security-team@suse.de | --- Comment #72 from Marcus Meissner 2013-05-03 11:49:44 UTC --- wodim is not setuid root, so cdrecord should also be without any root rights. Any special permissions for cdrecord will only be accepted if there are sound technical reasons, and none of these were listed or referenced in this bugreport yet. (and no, giving out capabilities that are largely equivalent to setuid root are not the solution either). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c74 Jan Engelhardt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|joerg.schilling@fokus.fraun | |hofer.de | --- Comment #74 from Jan Engelhardt 2013-05-03 18:20:09 CEST --- We are working to have cdrecord use capabilities instead of setuid.

Any special permissions for cdrecord will only be accepted if there are sound technical reasons, and none of these were listed or referenced in this bugreport yet.

Well the reasons have been posted quite clearly IMO. There was, - support for vendor-specific SCSI commands (I think this is what warrants CAP_SYS_RAWIO), - and support for non-CDROM-type devices - attain RT scheduling etc. The question is only: does openSUSE want to ship that, or a reduced cdrtools that only can deal with standardized MMC CDROM drives at normal priority, for example. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c76 --- Comment #76 from Jörg Schiling 2013-05-03 19:35:18 UTC --- I hope there is a will to come to a useful fact based result. This of course means that we cannot waste out time with false claims from the people behind wodim. I am interested in working cdrtools and I explained what is needed in vast details. Up to now there was not a single argument against that, so I propose that we just agree to do what I explained. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c77 --- Comment #77 from Marcus Meissner 2013-05-03 22:47:53 UTC --- - support for vendor-specific SCSI commands (I think this is what warrants CAP_SYS_RAWIO), This is possible without CAP_SYS_RAWIO as i can do it with libgphoto2 just fine from pure userspace. => There however seems to be some special IO transfer modes that need it if you look at the source. I cannot estimate their necessity for better cd burning. - and support for non-CDROM-type devices Basically just need udev ACL rules if needed. Is definitely not a common case for users of cdrecord here. - realtime... This is where I do not know the state of the art of cd burning, but I thought it is not necessary these days anymore. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c79 --- Comment #79 from Bernhard Wiedemann 2013-05-04 17:00:10 CEST --- This is an autogenerated message for OBS integration: This bug (550021) was mentioned in https://build.opensuse.org/request/show/174492 Factory / permissions -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c81 --- Comment #81 from Dave Plater 2013-05-05 12:35:40 UTC --- Also brasero has no problem blanking a r/w cd using the new cdrecord. Time taken to perform the task was normal. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c83 Marcus Meissner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|meissner@suse.com | --- Comment #83 from Marcus Meissner 2013-05-08 14:32:06 UTC --- I made some adjustments that this works now, was not familar with caps handling in permissions and now am. As I also had added overrides in "permissions" already this is kind of hard right now. I resubmitted a permissions package with the entries disabled so we can test it via the overrides in the current package. It will be a bit until it has passed the checkin workflow again. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c85 --- Comment #85 from Jörg Schiling 2013-05-08 15:25:20 UTC --- I am not sure how permissions are handled at packet instalation time but if the files "cdrecord.secure" or "cdrecord.paranoid" are used, this results in an installaton that may only be used by "root". Cdrtools with path/to/{cdrecord!cdds2wav!readcd} set to suid root is secure and an installation with the above named fcaps is also secure in case cdrtools have been compiled with libcap support. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c87 --- Comment #87 from Dave Plater 2013-05-09 09:03:59 UTC --- I'm in the process of sorting dependencies of dvd+rw-tools. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c89 --- Comment #89 from Dave Plater 2013-05-09 16:03:34 UTC --- (In reply to comment #88) I'm busy chatting to the maintainer, Vladimir and I suggested moving it to him and he hasn't indicated yes or no to that question but he's prepared to change the Requires: to the binary links. The packages that depend on dvd+rw-tools are mostly in Packman.except for k3b. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c91 --- Comment #91 from Dave Plater 2013-05-11 09:06:53 UTC --- working on file-roller's dependency on genisoimage which unfortunately has conflicting binary names but is used for viewing iso's. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c93 --- Comment #93 from Jörg Schiling 2013-05-11 11:24:42 UTC --- I did not try mkisofs with grub2 by my own, but I have been told that you need to use -modification-date to set up a UUID for the image and you may need -eltorito-platform to set up a boot for EFI platforms. genisoimage is not expected to include such support as the related code was added to mkisofs after 2004. You may like to check your calling code for possible simplifying. In general, it makes sense to check for the plenty of new features that have been added to mkisofs after september 2004. More than 50% of the current code base was added after september 2004. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c95 --- Comment #95 from Dave Plater 2013-05-11 12:35:03 UTC --- (In reply to comment #94) If any bugs appear you will be the first person to know. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c97 --- Comment #97 from Jörg Schiling 2013-05-11 18:18:58 UTC --- (In reply to comment #96) dvd+rwtools (growisofs) have been designed for mkisofs. If growisofs failes, there may be wither a bug in genisoimage (if used) or a drive incompatibility in growisofs. Cdrecord carefully regards the SCSI standard and implements various workarounds for firmwarebugs in the drives. growisofs has no firmware bug workarounds and partially makes strange assoumptions on what a drive is expected to accept as a reply to a mode change operation. There seems to be no update since 5 years. This is why many people report that in cdrecord causes less problems with writing DVDs and BluRays than growisofs. The k3b maintainers know this and some time ago started to prefer cdrecord over growisofs by default. AFAIK, genisoimage does not implement anything of interest that is not also supported by mkisofs. I am in hope that GUIs will implement support for the various new features in mkisofs and cdrecord once more Linux distros support mkisofs again. genisoimage creates plenty of defects in the created ISO images. mkisofs currently has no known bug and correctly handles deep directory nesting and hides "rr_moved". -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c99 --- Comment #99 from Dave Plater 2013-05-12 08:21:32 UTC --- (In reply to comment #98) cdrtools still has intermittent build failures on the post script. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c101 --- Comment #101 from Jan Engelhardt 2013-05-12 12:39:54 CEST --- There are three possibilities: 1. file-roller depends on genisoimage isoinfo, then it should Require: genisoimage. (This is what f-r currently uses.) 2. f-r depends on cdrtools isoinfo, then it should Require: mkisofs. 3. f-r does not care, then it should Require: /usr/bin/isoinfo instead. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c103 --- Comment #103 from Jörg Schiling 2013-05-12 11:06:03 UTC --- (In reply to comment #101) how about removing isoinfo from cdrkit? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c105 --- Comment #105 from Jan Engelhardt 2013-05-14 16:45:31 CEST --- (In reply to comment #103)

how about removing isoinfo from cdrkit?

No objections here. Dave, do you know about any software that - for whatever reason - would depend on cdrkit-ish isoinfo? Would we have to provide that as /usr/bin/cdrkit-isoinfo instead? (In reply to comment #99)

cdrtools still has intermittent build failures on the post script. (In reply to comment #104) Is it possible that one or more compile platforms do not have the correct capabilities listed in their known permissions?

submit request 175574 should fix that. (It is actually the post-build checks from /usr/bin/build, not the %post section itself.) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c107 Marcus Meissner changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|meissner@suse.com | --- Comment #107 from Marcus Meissner 2013-05-16 16:26:37 UTC --- The permissions will be done in the permissions SRPM and not in the package itself. So the current snippets are for multimedia:apps/cdrtools testing purposes only. After the Security Team (e.g. me) is convinced of what are required they are added. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c109 --- Comment #109 from Jan Engelhardt 2013-05-16 18:44:40 CEST ---

(although I can send _all_ SCSI commands to my libgphoto2 SCSI cameras, so it must be something different I am not aware of.)

Yes. You fail to recognize that your camera is outside the scope of "CD". As has been said before, SCSI resets want to have SYS_ADMIN or SYS_RAWIO as we speak. Your gphoto code does not issue any SCSI resets AFAICS, so of course gphoto won't need such caps. But cdrecord-libscg can issue such commands. (They are in fact HBA commands, not device commands, which is likely why it requires more permissions than what you get with the plain ACL'd device node.) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c110 --- Comment #110 from Bernhard Wiedemann 2013-06-11 06:00:09 CEST --- This is an autogenerated message for OBS integration: This bug (550021) was mentioned in https://build.opensuse.org/request/show/178515 Factory / permissions -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c112 --- Comment #112 from Jan Engelhardt 2013-06-11 11:47:30 CEST --- r32 is already queued. 178393 multimedia:apps/cdrtools -> openSUSE:Factory 2013-06-10T14:55:35 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c114 --- Comment #114 from Marcus Meissner 2013-06-17 06:18:16 UTC --- A technical explanation would be helpful again. I see the need to have destructive operations like burning reliable and single-tasked. But for repeatable actions like reading ... I current do not see special privileges necessary. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c116 --- Comment #116 from Jörg Schiling 2013-07-08 11:07:20 UTC --- Just an additional note: the discussion about which fine grained privileges are needed for the various programs from cdrtools did take place in January 2006 - this is 7.5+ years ago. Sun people did participate in this discussion, but Linux people have not been interested. Now this decision is history already and people should just accept that settled decisions will not be changed. If suse decides to grant less privileges to cdrtols than what has been agreed on in January 2006, this is a bug in suse. Regarding cdda2wav - I believe this has been explained many times already in the past: some drives behave different when you don't read the data stream as fast as it is available. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c117 Jan Engelhardt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #117 from Jan Engelhardt 2013-12-04 17:11:21 CET --- cdrtools is in for 13.2. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c118 qvacfcajdjw@mailinator.com M8R-2yr72d@mailinator.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #118 from qvacfcajdjw@mailinator.com M8R-2yr72d@mailinator.com 2014-02-26 12:26:11 UTC --- Someone added cdrtools back to OpenSUSE Factory: https://build.opensuse.org/package/show/multimedia:apps/cdrtools However, the *LICENSING PROBLEM* is still unresolved, which caused cdrtools to be removed in the first place. https://bugzilla.novell.com/show_bug.cgi?id=856805 The reason why Red Hat, Ubuntu, Debian etc. do no longer use cdrtools is that the license is debated, and thus OpenSUSE may lack a proper license to distribute binary packages of cdrtools either. This *really* needs to be carefully handled by the legal team. I cannot find evidence of a confirmation from the legal team that cdrtools suddenly can be distributed again. Unfortunately, the owner of the package at OpenSUSE also seems unwilling to discuss the licencing issue. <b>Please, someone get some official legal decisionmaker from OpenSUSE on board, to find a proper solution.</b> Instead of leaving users in the muddy water of Schily-hates-Debian FUD. Someone must be able to decide whether this is a problem for OpenSUSE too, or not. Thank you. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c Bug 550021 depends on bug 856805, which changed state. Bug 856805 Summary: multimedia:apps/cdrtools: Licensing issues http://bugzilla.novell.com/show_bug.cgi?id=856805 What |Old Value |New Value ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c121 --- Comment #121 from Juergen Weigert 2014-02-27 11:44:03 UTC --- (In reply to comment #119)

Also, please recall that Joerg Schilling has threatened SuSE with a lawsuit before:

http://lwn.net/Articles/346558/

The threat was about *not* distributing Joergs original version. In comment 118 you raise concers that we *do* distribute Joergs original version. Isn't that a contradiction? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=550021 https://bugzilla.novell.com/show_bug.cgi?id=550021#c Bug 550021 depends on bug 856805, which changed state. Bug 856805 Summary: multimedia:apps/cdrtools: Licensing issues http://bugzilla.novell.com/show_bug.cgi?id=856805 What |Old Value |New Value ---------------------------------------------------------------------------- Status|REOPENED |CLOSED Resolution| |FIXED -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.