Re: Cannot connect with android clients xabber or yaxim to jabberd2

2014-01-08 Thread Guido Winkelmann 
On Monday 06 January 2014 22:06:32 Fabian Wenk wrote:
 Hello Guido
 
 On 06.01.2014 21:00, Guido Winkelmann wrote:
  For some reason, I cannot connect to jabberd2 2.3.1 with either xabber or
  yaxim. I originally thought this was a xabber bug, so I reported it here:
  
  https://github.com/redsolution/xabber-android/issues/268
  
  However, it seems there are other people who suddenly have that problem
  after switching to jabberd2 2.3.1.
  
  Unfortunately, xabber does not display a useful error message, but yaxim
  says Session establishment not offered by server.
 
 A friend also had the problem with his xabber client connecting
 after he did upgrade jabberd from 2.2.17 to 2.3.1. After I have
 just discussed this issue with him again (as I did not had any
 problems, but I do not use it from Android), he pocked around in
 the settings and did deactivate the option (translated from German):
use SASL authentication (recommended) (deactivate for very
 old servers)
 in xabber and he is able to connect again.

You are right, if I disable SASL auth, I can login via xabber again.

Guido

Re: s2s: timed out dns lookups

2013-12-28 Thread Guido Winkelmann 
Hi Marcin,

Am Samstag, 28. Dezember 2013, 17:00:24 schrieb Marcin Mirosław:
 W dniu 2013-12-27 22:41, Guido Winkelmann pisze:
 [...]
 
  I'm using jabberd2 2.3.1 on Gentoo, installed from portage, and udns 0.2,
  both compiled with GCC 4.7.3. The problem also exists with udns 0.1 and
  GCC 4.5.4, though.
  
  Does anyone have any idea what might be the problem here?
 
 Hi!
 Please look at https://bugs.gentoo.org/show_bug.cgi?id=400905 and
 http://comments.gmane.org/gmane.network.jabber.jabberd2/1469

I found that, but your workaround does not work for me.
 
 What CFLAGS are you using?

Just
CFLAGS=-O2 -mcpu=ultrasparc -pipe

Guido

s2s: timed out dns lookups

2013-12-27 Thread Guido Winkelmann 
Hi,

I've recently switched from jabberd14 (yeah, I know...) to jabberd2, and I'm 
having trouble with s2s timing out a lot on trying to resolve the names of 
other Jabber servers from contacts on my roster. I'm getting a lot of lines 
like these in /var/log/messages:

Dec 27 22:15:21 blish jabberd/s2s[20464]: dns lookup for jabber.ccc.de timed 
out
Dec 27 22:15:22 blish jabberd/s2s[20464]: dns lookup for freistaat-linden.de 
timed out
Dec 27 22:15:22 blish jabberd/s2s[20464]: dns lookup for arara.de timed out
Dec 27 22:15:22 blish jabberd/s2s[20464]: dns lookup for jabber.org timed out

Sometimes, but rarely, the lookup for a server works and I can see the online 
status of a contact or two, but most of the time, most of my roster is crossed 
out as unreachable.

Manual lookup of these names with, for example

dig -t any _xmpp-server._tcp.jabber.org

works with no problems.

I'm using jabberd2 2.3.1 on Gentoo, installed from portage, and udns 0.2, both 
compiled with GCC 4.7.3. The problem also exists with udns 0.1 and GCC 4.5.4, 
though.

Does anyone have any idea what might be the problem here?

Guido

How to remove a user from db backend?

2012-12-18 Thread Guido Winkelmann 
Hi,

How can I remove a user's data from the session manager if I'm using the db 
backend for storage?

I'm using LDAP for authentication. If I want to remove a user, I can, of 
course, just remove him from the LDAP server to make sure he cannot log in 
anymore. However, if I do this, the users old data, like roster contents, 
subscription status to other JIDs, outstanding messages for offline delivery, 
vcard and so on will still be stored in the session manager. If I now add 
another user who happens to have the same JID, he will get to see that data as 
his own.

(Possible scenario where that might happen: A user succesfully contests 
another users right to use that particular nickname on that particular 
server.)


Guido

Re: two ldap modules (Re: LDAP Auth: Require user to be in specified LDAP-group)

2012-12-13 Thread Guido Winkelmann 
Am Mittwoch, 12. Dezember 2012, 09:40:49 schrieb Justin T Pryzby:
 I compared the two ldap modules here:
 http://www.mail-archive.com/jabberd2@lists.xiaoka.com/msg01381.html
 (Was it really three years ago??)
 
 Is there any reason to maintain both?  What does full mean in
 ldapfull?

At a guess, this might be for forward compatibility for configuration files. 
ldap and ldapfull are not configured exactly the same way, so if you merge 
them (and maybe make ldapfull a synonym for ldap), someone's configuration 
will inevitably break, especially if they install the update without 
thoroughly reading the changelog.

Two examples off the top of my head:

- ldapfull specifies the LDAP server to use as a free form URI, which it just 
passes on unchanged to the underlying API (which is IMHO the way it should be 
done), while ldap takes host and port as two separate directives
- ldap supports custom filters, ldapfull does not

Guido

Re: LDAP Auth: Require user to be in specified LDAP-group

2012-12-13 Thread Guido Winkelmann 
Ah, nobody use that yet, please. I just realized I forgot some ldap_memfree() 
calls in _ldapfull_check_password(), so this will probably leak memory...

Am Donnerstag, 13. Dezember 2012, 14:47:12 schrieb Guido Winkelmann:
 The same patch for git master.

Re: LDAP Auth: Require user to be in specified LDAP-group

2012-12-13 Thread Guido Winkelmann 
The first patch had a memory leak.

Am Mittwoch, 12. Dezember 2012, 17:07:34 schrieb Guido Winkelmann:
 This patch appears to work. Note, I have only done superficial testing
 (checked that I can log in as a user who is in the specified group and that
 I can not log in as one that is not in this group). I have not tested this
 against AD, only OpenLDAP.
 
 This patch applies to 2.2.17, but not to git-master.
 
   Guidodiff -rup jabberd-2.2.17-orig/etc/c2s.xml.dist.in jabberd-2.2.17/etc/c2s.xml.dist.in
--- jabberd-2.2.17-orig/etc/c2s.xml.dist.in	2012-05-22 22:27:51.0 +0200
+++ jabberd-2.2.17/etc/c2s.xml.dist.in	2012-12-12 16:39:54.490003311 +0100
@@ -546,6 +546,15 @@
   !--
   validattrvalid/validattr
   --
+
+  !-- Group that users must be members of
+   If this is set, only user that are members of the specified LDAP
+   group can log in. The group must be specified with its full 
+   distinguished name --
+  !--
+  group_dncn=jabberdusers,ou=servicegroups,dc=example,dc=com/group_dn
+  --
+
   fulluid/
   !-- If pwscheme is not defined, then passwords are stored in clear
text and digest authentication may be done.
diff -rup jabberd-2.2.17-orig/storage/authreg_ldapfull.c jabberd-2.2.17/storage/authreg_ldapfull.c
--- jabberd-2.2.17-orig/storage/authreg_ldapfull.c	2012-02-19 14:23:09.0 +0100
+++ jabberd-2.2.17/storage/authreg_ldapfull.c	2012-12-13 16:30:13.690004078 +0100
@@ -68,6 +68,7 @@ typedef struct moddata_st
 char *objectclass;
 char *uidattr;
 char *validattr;
+char *group_dn;
 char *pwattr;
 char *pwscheme;
 
@@ -583,6 +584,50 @@ retry:
 return dn;
 }
 
+/** Is this user part of the given LDAP group? */
+static int _ldapfull_user_in_group(moddata_t data, char *user_dn, char *group_dn)
+{
+LDAPMessage *result, *entry;
+int tried = 0;
+char filter[1024];
+ 
+log_debug(ZONE, checking whether user with dn %s is in group %s, user_dn, group_dn);
+
+memset(filter, 0, 1024);
+snprintf(filter, 1024, (member=%s), user_dn); // TODO Check if snprintf result was truncated
+
+retry:
+if(ldap_search_s(data-ld, group_dn, LDAP_SCOPE_BASE, filter, NULL, 0, result))
+{
+if( tried++  LDAPFULL_SEARCH_MAX_RETRIES ) {
+log_debug(ZONE, ldap: group search fail, will retry; %s: %s, filter, ldap_err2string(_ldapfull_get_lderrno(data-ld)));
+_ldapfull_unbind(data);
+if( _ldapfull_connect_bind(data) == 0 ) {
+goto retry;
+} else {
+return 0;
+}
+}
+log_write(data-ar-c2s-log, LOG_ERR, ldap: group search %s failed: %s, filter, ldap_err2string(_ldapfull_get_lderrno(data-ld)));
+_ldapfull_unbind(data);
+return 0;
+}
+
+entry = ldap_first_entry(data-ld, result);
+if(entry == NULL)
+{
+ldap_msgfree(result);
+
+return 0;
+}
+else 
+{
+ldap_msgfree(result);
+
+return 1;
+}
+}
+
 /** do we have this user? */
 static int _ldapfull_find_user_dn(moddata_t data, char *username, char *realm, char **dn)
 {
@@ -601,6 +646,11 @@ static int _ldapfull_user_exists(authreg
 {
 char *dn;
 if (_ldapfull_find_user_dn((moddata_t) ar-private, username, realm, dn)) {
+if(((moddata_t) ar-private)-group_dn != NULL
+ !_ldapfull_user_in_group((moddata_t) ar-private, dn, ((moddata_t) ar-private)-group_dn)) {
+ldap_memfree(dn);
+return 0;
+}
 ldap_memfree(dn);
 return 1;
 }
@@ -748,22 +798,54 @@ static int _ldapfull_check_password(auth
 {
 moddata_t data = (moddata_t) ar-private;
 char buf[LDAPFULL_PASSBUF_MAX];
+char *dn = NULL;
 
 log_debug(ZONE, checking password for %s, username);
 
 if(password[0] == '\0')
 return 1;
 
+if(data-group_dn != NULL) {
+if (!_ldapfull_find_user_dn(data, username, realm, dn))
+return 1;
+}
 /* The bind scheme doesn't need the password read first, so short circuit
the whole passhash scheme */
-if (!strcmp(data-pwscheme, bind))
-return _ldapfull_check_password_bind(ar, username, realm, password);
+if (!strcmp(data-pwscheme, bind)) {
+if(_ldapfull_check_password_bind(ar, username, realm, password) == 0) {
+if(data-group_dn != NULL  !_ldapfull_user_in_group(data, dn, data-group_dn)) {
+ldap_memfree(dn);
+return 1;
+}
+else {
+ldap_memfree(dn);
+return 0;
+}
+}
+}
 
 if( _ldapfull_get_password(ar,username,realm,buf) != 0  ) {
+if(dn != NULL)
+ldap_memfree(dn);
 return 1;
 }
 
-return ! _ldapfull_check_passhash(data,buf,password);
+if(_ldapfull_check_passhash(data,buf,password)){
+if(data-group_dn != NULL  !_ldapfull_user_in_group

Re: LDAP Auth: Require user to be in specified LDAP-group

2012-12-12 Thread Guido Winkelmann 
This patch appears to work. Note, I have only done superficial testing 
(checked that I can log in as a user who is in the specified group and that I 
can not log in as one that is not in this group). I have not tested this 
against AD, only OpenLDAP.

This patch applies to 2.2.17, but not to git-master.

Guidodiff -rup jabberd-2.2.17-orig/etc/c2s.xml.dist.in jabberd-2.2.17/etc/c2s.xml.dist.in
--- jabberd-2.2.17-orig/etc/c2s.xml.dist.in	2012-05-22 22:27:51.0 +0200
+++ jabberd-2.2.17/etc/c2s.xml.dist.in	2012-12-12 16:39:54.490003311 +0100
@@ -546,6 +546,15 @@
   !--
   validattrvalid/validattr
   --
+
+  !-- Group that users must be members of
+   If this is set, only user that are members of the specified LDAP
+   group can log in. The group must be specified with its full 
+   distinguished name --
+  !--
+  group_dncn=jabberdusers,ou=servicegroups,dc=example,dc=com/group_dn
+  --
+
   fulluid/
   !-- If pwscheme is not defined, then passwords are stored in clear
text and digest authentication may be done.
diff -rup jabberd-2.2.17-orig/storage/authreg_ldapfull.c jabberd-2.2.17/storage/authreg_ldapfull.c
--- jabberd-2.2.17-orig/storage/authreg_ldapfull.c	2012-02-19 14:23:09.0 +0100
+++ jabberd-2.2.17/storage/authreg_ldapfull.c	2012-12-12 16:52:30.43587 +0100
@@ -68,6 +68,7 @@ typedef struct moddata_st
 char *objectclass;
 char *uidattr;
 char *validattr;
+char *group_dn;
 char *pwattr;
 char *pwscheme;
 
@@ -583,6 +584,50 @@ retry:
 return dn;
 }
 
+/** Is this user part of the given LDAP group? */
+static int _ldapfull_user_in_group(moddata_t data, char *user_dn, char *group_dn)
+{
+LDAPMessage *result, *entry;
+int tried = 0;
+char filter[1024];
+ 
+log_debug(ZONE, checking whether user with dn %s is in group %s, user_dn, group_dn);
+
+memset(filter, 0, 1024);
+snprintf(filter, 1024, (member=%s), user_dn); // TODO Check if snprintf result was truncated
+
+retry:
+if(ldap_search_s(data-ld, group_dn, LDAP_SCOPE_BASE, filter, NULL, 0, result))
+{
+if( tried++  LDAPFULL_SEARCH_MAX_RETRIES ) {
+log_debug(ZONE, ldap: group search fail, will retry; %s: %s, filter, ldap_err2string(_ldapfull_get_lderrno(data-ld)));
+_ldapfull_unbind(data);
+if( _ldapfull_connect_bind(data) == 0 ) {
+goto retry;
+} else {
+return 0;
+}
+}
+log_write(data-ar-c2s-log, LOG_ERR, ldap: group search %s failed: %s, filter, ldap_err2string(_ldapfull_get_lderrno(data-ld)));
+_ldapfull_unbind(data);
+return 0;
+}
+
+entry = ldap_first_entry(data-ld, result);
+if(entry == NULL)
+{
+ldap_msgfree(result);
+
+return 0;
+}
+else 
+{
+ldap_msgfree(result);
+
+return 1;
+}
+}
+
 /** do we have this user? */
 static int _ldapfull_find_user_dn(moddata_t data, char *username, char *realm, char **dn)
 {
@@ -601,6 +646,11 @@ static int _ldapfull_user_exists(authreg
 {
 char *dn;
 if (_ldapfull_find_user_dn((moddata_t) ar-private, username, realm, dn)) {
+if(((moddata_t) ar-private)-group_dn != NULL
+ !_ldapfull_user_in_group((moddata_t) ar-private, dn, ((moddata_t) ar-private)-group_dn)) {
+ldap_memfree(dn);
+return 0;
+}
 ldap_memfree(dn);
 return 1;
 }
@@ -748,22 +798,40 @@ static int _ldapfull_check_password(auth
 {
 moddata_t data = (moddata_t) ar-private;
 char buf[LDAPFULL_PASSBUF_MAX];
+char *dn;
 
 log_debug(ZONE, checking password for %s, username);
 
 if(password[0] == '\0')
 return 1;
 
+if(data-group_dn != NULL) {
+if (!_ldapfull_find_user_dn(data, username, realm, dn))
+return 1;
+}
 /* The bind scheme doesn't need the password read first, so short circuit
the whole passhash scheme */
-if (!strcmp(data-pwscheme, bind))
-return _ldapfull_check_password_bind(ar, username, realm, password);
+if (!strcmp(data-pwscheme, bind)) {
+if(_ldapfull_check_password_bind(ar, username, realm, password) == 0) {
+if(data-group_dn != NULL  !_ldapfull_user_in_group(data, dn, data-group_dn))
+return 1;
+else
+return 0;
+}
+}
 
 if( _ldapfull_get_password(ar,username,realm,buf) != 0  ) {
 return 1;
 }
 
-return ! _ldapfull_check_passhash(data,buf,password);
+if(_ldapfull_check_passhash(data,buf,password)){
+if(data-group_dn != NULL  !_ldapfull_user_in_group(data, dn, data-group_dn))
+	return 1;
+else
+return 0;
+}
+else
+	return 1;
 }
 
 static int _ldapfull_create_user(authreg_t ar, char *username, char *realm) {
@@ -856,6 +924,8 @@ DLLEXPORT int ar_init(authreg_t ar)

Re: LDAP Auth: Require user to be in specified LDAP-group

2012-12-11 Thread Guido Winkelmann 
Am Dienstag, 11. Dezember 2012, 11:43:49 schrieb Eric V. Smith:
 On 12/11/2012 11:11 AM, Guido Winkelmann wrote:
  Hi,
  
  I'm trying to integrate Jabberd2 into my single-account scheme using LDAP,
  and I'm running into problems with that.
  
  One of my requirements for this is that I need to be able to specify for
  every user exactly which services he or she is allowed to access, so
  that, for example, a user who only needs access to SMTP and IMAP services
  is not also automatically able to login via SSH or FTP. For the services
  I have running so far, I was able to implement this by creating a new
  LDAP group (with objectClass: groupOfNames) for each service and having
  every service check whether a freshly authenticated user is a member of
  the respective group for this service before granting access.
  
  Unfortunately, jabberd2 does not appear to support this (or PAM, which
  would have provided a nice workaround).
  
  Does anyone know of any other way to achieve this?
 
 I use pam with jabberd2:
 http://www.jabberdoc.org/section04_6.html
 
 And in pam I require a specific group, and I'm using LDAP as the account
 backend. Works like a charm.

Ah, so it does work! I was going by the example config file for c2s, which did 
not mention pam, so I thought it just wasn't supported...

Anyway, I've been reading authreg_ldapfull.c for a bit, and while I'm not very 
familiar with the code base yet, it looks like simply implementing the group 
check feature right there would not be that hard. I think I will try my luck 
with that, and if it doesn't work out go back to PAM.

Re: LDAP Auth: Require user to be in specified LDAP-group

2012-12-11 Thread Guido Winkelmann 
Am Dienstag, 11. Dezember 2012, 18:12:42 schrieb Guido Winkelmann:
 Am Dienstag, 11. Dezember 2012, 17:50:03 schrieb Tomasz Sterna:
  Dnia 2012-12-11, wto o godzinie 17:11 +0100, Guido Winkelmann pisze:
   For the services I have running so far, I was able to implement this
   by creating a new LDAP group (with objectClass: groupOfNames) for each
   service and having every service check whether a freshly authenticated
   user is a member of the respective group for this service before
   granting access.
  
  Quoting
  https://github.com/jabberd2/jabberd2/blob/master/etc/c2s.xml.dist.in#L634
  
!-- Alternatively to uidattr/ and append-realm/ you may

 specify full LDAP search query/ that will be used to
 get user objects from directory.
 
 The following replacements take place:
 %u  is replaced by user login name
 %r  is replaced by user login realm
 
 When query/ is specified, uidattr/ and append-realm/
 are unused and take no effect. --

!--
query(amp;(mail=%u@%r)(objectClass=inetOrgPerson))/query
--
  
  Isn't this wat you are looking for?
 
 Hm, yes, but this is in that ldap-module (as opposed to ldapfull), which has
 its own problem: It does not allow me to specify the URI of the LDAP server
 as free form, so I cannot use the ldapi protocol. (The ldap server is
 running locally, listening on a unix socket, and I do not want to configure
 it to listen on any IP sockets.)

Also, I think using filters to check whether a given user is part of a given 
group only works with AD but not with OpenLDAP, because the latter puts group 
members as attributes into the group object in the form of member attributes, 
while the former puts group memberships into the user objects in the form of 
memberOf attributes.

Guido

Re: jabberd-2.2.17 release

2012-11-09 Thread Guido Winkelmann 
On Sunday 26 August 2012 14:14:01 Tomasz Sterna wrote:
 Next jabberd2 release is available.
 
 Get 2.2.17 release at GitHub:
 https://github.com/downloads/Jabberd2/jabberd2/jabberd-2.2.17.tar.xz

I just noticed that the project website under 
http://codex.xiaoka.com/wiki/jabberd2:start is still pointing to 2.2.16 as the 
newest release. Might wanna fix that...

Guido

Re: Missing images in documentation

2012-10-11 Thread Guido Winkelmann 
Am Donnerstag, 11. Oktober 2012, 14:42:57 schrieb Tomasz Sterna:
 Dnia 2012-08-18, sob o godzinie 03:19 +0200, Guido Winkelmann pisze:
  I just noticed that the documentation under
  https://github.com/Jabberd2/jabberd2/wiki/InstallGuide-QuickStartGuide
  is missing a lot of images. From the context, it looks like those
  images are really quite central to the text, containing information
  that is not available otherwise.
 
 These are not images.
 These are code blocks, like this:
 {{{
  yum install jabberd
 }}}
 
 For some reason GitHub's Creole renderer now interprets them as inline
 images of syntax {{...}} :-/
 
 I reported this issue to them.

That's nice.

In the mean time, is there some way for the rest of us to view the 
documentation unformatted? As it is right now, it is practically unusable 
because the most important parts are all missing...

Guido

Missing images in documentation

2012-08-17 Thread Guido Winkelmann 
Hi,

I just noticed that the documentation under 
https://github.com/Jabberd2/jabberd2/wiki/InstallGuide-QuickStartGuide
is missing a lot of images. From the context, it looks like those images are 
really quite central to the text, containing information that is not available 
otherwise.

Guido