lprng-devel Mailing List for LPRng

On Mon, Jan 28, 2008 at 09:47:53PM +0100, Bernhard R. Link wrote:
> I've commited attached patch to cvs, which should fix those.
It looks like the sort of thing I was going to try. I'd say give it a
week or so then perhaps another rc which will have the krb5 patch and
this.

I should push down my minor patches from the Debian archive into the
mainline too. Just simple things like the manual page has no section
number.

 - Craig
-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/                             csmall at : enc.com.au
http://www.debian.org/          Debian GNU/Linux, software should be Free 

* Craig Small <csm...@en...> [080124 13:15]:
> Looks like there is some excessive linking going on too, not a biggie
> but something that can get trimmed later.
> 
> dpkg-shlibdeps: warning: debian/lprng/usr/lib/lprng/filters/lpbanner
> shouldn't be linked with libcom_err.so.2 (it uses none of its symbols).
> dpkg-shlibdeps: warning: debian/lprng/usr/lib/lprng/filters/lpbanner
> shouldn't be linked with libssl.so.0.9.8 (it uses none of its symbols).
> dpkg-shlibdeps: warning: debian/lprng/usr/lib/lprng/filters/lpf
> shouldn't be linked with libkrb5.so.3 (it uses none of its symbols).
> dpkg-shlibdeps: warning: debian/lprng/usr/lib/lprng/filters/lpf
> shouldn't be linked with libcrypto.so.0.9.8 (it uses none of its
> symbols).
> dpkg-shlibdeps: warning: debian/lprng/usr/lib/lprng/filters/lpf
> shouldn't be linked with libcom_err.so.2 (it uses none of its symbols).
> dpkg-shlibdeps: warning: debian/lprng/usr/lib/lprng/filters/lpf
> shouldn't be linked with libssl.so.0.9.8 (it uses none of its symbols).

I've commited attached patch to cvs, which should fix those.

Hochachtungsvoll,
	Bernhard R. Link

On Sun, 27 Jan 2008, Bernhard R. Link wrote:

> I think the following patch (which I applied to cvs already) should restore
> the functionaly. Given I lack kerberos infrastructure to test it I'd be
> eager to hear if it works, too.

It works.  Thanks for the quick turnaround,

 	-Tim Abbott

* Tim Abbott <ta...@MI...> [080127 07:42]:
> In versions of lprng before the kerberos4 authtype was deprecated, 
> authtypes of the form "kerberos*" for * different from 4 were handled as 
> the standard "kerberos" authtype; below is part of the diff between the 
> current Lenny and Sid versions in common/user_auth.c:
> 
>  # if defined(MIT_KERBEROS4)
>         { "kerberos4", "kerberos", IP_SOCKET_ONLY, Send_krb4_auth, 0,0,0 },
>  # endif
> -       { "kerberos*", "kerberos", IP_SOCKET_ONLY, 0,           Krb5_send, 
> 0, Krb5_receive },
> +       { "kerberos", "kerberos", IP_SOCKET_ONLY, 0,           Krb5_send, 
> 0, Krb5_receive },
> +       { "k5conn", "kerberos", IP_SOCKET_ONLY, 0,           
> Krb5_send_nocrypt, 0, Krb5_receive_nocrypt },
>  #endif

This was a change by Patrick Powell (or perhaps from the people that
patched lprng to be called as transport from MacOS's cups, but included
in 2.8.32) to introduce the k5conn, the kerberos authenticated but not
encrypted connection method. I think it was added as Fix_send_auth not sends
the name instead of the config_tag so the server can distinguish them.
Other side effect should be that kerberos4 is also sent over the line,
so the kerberos4 tag is sent, which should be rejected because of
missing server_receive method.
I guess the best method is to revert this change and make k5conn send
k5conn instead of kerberos then. (And if anyone has kerberos4, I'd be
interested to know if that works, as the server would in the old code
call krb5_receive for send_krb4_auth, so I am confused).

I think the following patch (which I applied to cvs already) should restore
the functionaly. Given I lack kerberos infrastructure to test it I'd be
eager to hear if it works, too.

Thanks in advance,
	Bernhard R. Link

On Fri, Jan 25, 2008 at 05:02:35PM +0100, walter harms wrote:
> IMHO the question is 'is this documented' ?
> 
> If *yes* we can continue.
> if *no* we should do it.
It is not. So there are two mutually exclusive fixes:
  1) Fix the man page so it does mention it
  2) Fix the code so it doesn't need the file existing

> who do other programms handle logging ? i like the "rule of least surprise"
> and so far i can not remember a program that requires users to create a dummy
> file so the daemon/server can do logging.
Yes, I was thinking exactly the same thing.  Also, is there something
extra the programs that don't need a file already there do?

The easiest one is to fix the man page :)

 - Craig
-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/                             csmall at : enc.com.au
http://www.debian.org/          Debian GNU/Linux, software should be Free 

Bernhard R. Link wrote:
> * Craig Small <csm...@en...> [080125 00:37]:
>>  Regarding http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458003
>> the problem is that the create flag is not set so if the file does not
>> exist then the program dies.
>>
>> The fix is in line 741 of lpd.c:
>> if( Checkwrite(logfile, &statb, O_WRONLY|O_APPEND, 0, 0) != 2) {
>>
>> The first 0 should be 1 for create to be enabled.  
>>
>> My quesiton is, should the log file exist first?  Is there some security
>> issue in not mandating the file exists beofre the program starts?
>> I just want to make sure it wasn't designed this way.
> 
> The code in question is only in lpd. I've not heared of a situation
> where lpd was installed suid. And if it was, being able to append things
> to existing files would hardly be less dangerous than being allowed to
> create new files.
> 
> There are three little possible issues I see, though:
> 
> * Unless I misread the code, there lpd first chdirs to / before this.
> So relative patch names would end up at suprising places, as people
> are likely to run this as root.
> 
> * checkwrite is not looking at the umask, but (have not looked if
> Is_server is already set there, assuming it here) may use Spool_file
> permissions instead, which might be too broad for a file where passwords
> can end up.
> 
> * as the creating of the logfile is before changing the uid, the other
> way is also possible: if the file is created still as root with 0600
> and later written to as an other user. AFAIK Linux only checks
> permissions at open time, but I'm not sure about other OSes. (On the
> other hand, the current way the logfile (assuming I did not mix up something)
> can be a file that is not accessible by the finally running lpd, which
> gives some additional security, so I'm not sure if that is a good or bad
> thing.
> 

IMHO the question is 'is this documented' ?

If *yes* we can continue.
if *no* we should do it.

who do other programms handle logging ? i like the "rule of least surprise"
and so far i can not remember a program that requires users to create a dummy
file so the daemon/server can do logging.

re,
 wh

* Craig Small <csm...@en...> [080125 00:37]:
>  Regarding http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458003
> the problem is that the create flag is not set so if the file does not
> exist then the program dies.
> 
> The fix is in line 741 of lpd.c:
> if( Checkwrite(logfile, &statb, O_WRONLY|O_APPEND, 0, 0) != 2) {
> 
> The first 0 should be 1 for create to be enabled.  
> 
> My quesiton is, should the log file exist first?  Is there some security
> issue in not mandating the file exists beofre the program starts?
> I just want to make sure it wasn't designed this way.

The code in question is only in lpd. I've not heared of a situation
where lpd was installed suid. And if it was, being able to append things
to existing files would hardly be less dangerous than being allowed to
create new files.

There are three little possible issues I see, though:

* Unless I misread the code, there lpd first chdirs to / before this.
So relative patch names would end up at suprising places, as people
are likely to run this as root.

* checkwrite is not looking at the umask, but (have not looked if
Is_server is already set there, assuming it here) may use Spool_file
permissions instead, which might be too broad for a file where passwords
can end up.

* as the creating of the logfile is before changing the uid, the other
way is also possible: if the file is created still as root with 0600
and later written to as an other user. AFAIK Linux only checks
permissions at open time, but I'm not sure about other OSes. (On the
other hand, the current way the logfile (assuming I did not mix up something)
can be a file that is not accessible by the finally running lpd, which
gives some additional security, so I'm not sure if that is a good or bad
thing.

Hochachtungsvoll,
	Bernhard R. Link

Hello,
  I just uploaded 3.8.A to the Debian FTP master so it will soon be
pushed out to the various mirrors.  I'd apprecaite your assistance in
any subsequent bugs that may come through.

 - Craig
-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/                             csmall at : enc.com.au
http://www.debian.org/          Debian GNU/Linux, software should be Free 

Hello,
 Regarding http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458003
the problem is that the create flag is not set so if the file does not
exist then the program dies.

The fix is in line 741 of lpd.c:
if( Checkwrite(logfile, &statb, O_WRONLY|O_APPEND, 0, 0) != 2) {

The first 0 should be 1 for create to be enabled.  

My quesiton is, should the log file exist first?  Is there some security
issue in not mandating the file exists beofre the program starts?
I just want to make sure it wasn't designed this way.

I believe it is an oversight and it is fine for the print daemon to make
its own log file.

 - Craig
-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/                             csmall at : enc.com.au
http://www.debian.org/          Debian GNU/Linux, software should be Free 

* Craig Small <csm...@en...> [080124 13:15]:
> Looks like there is some excessive linking going on too, not a biggie
> but something that can get trimmed later.

If someone wants a nice little project, I think it would be very nice
if all those authentication code needing special libraries would be
moved into some form of plugins.

This would not only solve the problem of over-linking of some filters,
but also reduce the runtime dependencies massively. (Currently you
have to decide at compile time what authentications you want to support
and the generated binaries will then need all those libraries to run,
even when the authentication is not used).

The hard parts of this would to separate the code out (I didn't look to
deep, but it might be quite interwoven), inventing some clean API
(ideally not having to offer all of LPRng's internals to those plugins)
and some idea to build those (currently we get away without libtool,
which makes the whole build much more small and nice, so ideally those
authentication plugins would even be separate modules with their own
build system, but that would definitly need a even cleaner API).

> I was trying to find a list of known fixed bugs in this release linking
> them back to Debian ones but it doesnt look like it was tracked :(
> I'm tired now, releasing packaged when tired gives bad results (painful
> expriences show) so I'll have a look at it again tomorrow.

I've just looked over the open bugs on lprng in the Debian BTS, and I
don't see much (except perhaps 361925) being fixed. Without looking
deeper I did not even found anything that I am sure is a bug in LPRng
itself (except the too many open files thing...)


Hochachtungsvoll,
	Bernhard R. Link

On Thu, Jan 24, 2008 at 10:32:51AM +0100, Bernhard R. Link wrote:
> I've uploaded a rc2 to sf.net. I guess without some testing we will
> never end up at a release, and I think Debian packages would be a good
> way to get some testing...

I've started building the package, it seems to be working ok with not
too many warnings, just probablt stuff that can be cleaned up.

Looks like there is some excessive linking going on too, not a biggie
but something that can get trimmed later.

dpkg-shlibdeps: warning: debian/lprng/usr/lib/lprng/filters/lpbanner
shouldn't be linked with libcom_err.so.2 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/lprng/usr/lib/lprng/filters/lpbanner
shouldn't be linked with libssl.so.0.9.8 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/lprng/usr/lib/lprng/filters/lpf
shouldn't be linked with libkrb5.so.3 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/lprng/usr/lib/lprng/filters/lpf
shouldn't be linked with libcrypto.so.0.9.8 (it uses none of its
symbols).
dpkg-shlibdeps: warning: debian/lprng/usr/lib/lprng/filters/lpf
shouldn't be linked with libcom_err.so.2 (it uses none of its symbols).
dpkg-shlibdeps: warning: debian/lprng/usr/lib/lprng/filters/lpf
shouldn't be linked with libssl.so.0.9.8 (it uses none of its symbols).

I was trying to find a list of known fixed bugs in this release linking
them back to Debian ones but it doesnt look like it was tracked :(
I'm tired now, releasing packaged when tired gives bad results (painful
expriences show) so I'll have a look at it again tomorrow.


- Craig
-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/                             csmall at : enc.com.au
http://www.debian.org/          Debian GNU/Linux, software should be Free 

Bernhard R. Link wrote:
> * Craig Small <csm...@en...> [080123 23:02]:
>>   Is there going to be a release soon?  I'm carrying a fair few bugs in
>> the Debian BTS that I would like to clear out.  So I was going to make a
>> cvs snapshot and use that so at least the bugs will go.
> 
> I've uploaded a rc2 to sf.net. I guess without some testing we will
> never end up at a release, and I think Debian packages would be a good
> way to get some testing...
> 

Hi all,
can we agree to make the latest upload to our release ?
It would be great if the debian release is based on that so we get plenty testing.

re,
 wh

* Craig Small <csm...@en...> [080123 23:02]:
>   Is there going to be a release soon?  I'm carrying a fair few bugs in
> the Debian BTS that I would like to clear out.  So I was going to make a
> cvs snapshot and use that so at least the bugs will go.

I've uploaded a rc2 to sf.net. I guess without some testing we will
never end up at a release, and I think Debian packages would be a good
way to get some testing...

Hochachtungsvoll,
	Bernhard R. Link

Hello,
  Is there going to be a release soon?  I'm carrying a fair few bugs in
the Debian BTS that I would like to clear out.  So I was going to make a
cvs snapshot and use that so at least the bugs will go.

 - Craig
-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/                             csmall at : enc.com.au
http://www.debian.org/          Debian GNU/Linux, software should be Free