Re: webCDwriter: Native vs. Non-native package - MOSTLY SOLVED
At 01:33 10/05/2003 +0100, you wrote:
On Sat, May 10, 2003 at 12:53:16AM +0200, Jos? Luis Tall?n wrote:
> I have recently packaged webCDwriter [
> http://wwwhomes.uni-bielefeld.de/jhaeger/webCDwriter/ ] ( Closes:
#98594 ),
> but I have some questions to solve before i can ask my sponsor to
upload it
> for me to the archive. He suggested me to ask here.
>
> [ I will leave some policy-related questions for a later mail ]
>
> * Even though the upstream sources contain no debian subdirectory,
> dpkg-buildpackage says it is creating a Debian-native package,
> and thus creates no .diif.gz containing my debian subdirectory.
>
> I have put packagename-version.orig.tar.gz in the parent directory, per
the
> manual pages/howto/.. [can't remember now]
It needs to be called packagename_upstreamversion.orig.tar.gz. Note the
underscore.
Thanks. I originally did that way but changed to hyphen thinking i was
mistaken. That did it.
> *Since the program needs some SUID executables I do two things:
> - tell the user to run 'dpkg-reconfigure cdrecord' to enable recording for
> unprivileged users; warn about security implications
> - chown root.cdrom; chmod 4750 /usr/bin/{setScheduler,CDWverify} in the
> postinst, so that lintian does not give a warning.
If the default is setuid, I think that's a bad idea. If the executable
needs to be setuid, then it needs to be setuid, and you should override
the lintian warning rather than obfuscating the package so that lintian
doesn't notice (although get somebody who knows more about the situation
to verify that the override's correct beforehand).
where is "overriding lintian" documented ?
I thought i needed a file called "lintian.overrides", containing the exact
text for the warnings/errors i wanted to override ( read it somewhere )
This doesn't seem to work.... Which is the correct filename? Syntax?
Either way, you should be telling people to use dpkg-statoverride if
they want to change the permissions.
Also, 4750 is too tight; there's no reason not to make the executables
readable to unprivileged users, i.e. 4754. Policy 11.9 "Permissions and
owners" comments on this.
I did read it and do that the first time.
However, the upstream source does runtime validation of permissions -- It
will refuse to work with anything but 4750.
Thanks Colin and Leo.
J.L.
Reply to: