Re: echo module creating zombies
Original-Nachricht > Datum: Thu, 21 Feb 2013 12:12:59 -0500 > Von: Alan DeKok > An: FreeRadius users mailing list > Betreff: Re: echo module creating zombies > steff...@gmx.de wrote: > > Ok... I'm somewhere in between many and short time zombies with version > 2.2.0 - there is one zombie that stays until the next request and gets then > replaced by the next zombie. > > Well, that's what I said "they will get cleaned up when the server > receives more packets." Ah, ok, I interpreted the 2-3 seconds statement as 'they should disappear after 2-3 seconds on their own regardless of other packets coming in'. But this clears it up and I know what's going on, thanks ! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: echo module creating zombies
Original-Nachricht > Datum: Thu, 21 Feb 2013 09:39:30 -0500 > Von: Alan DeKok > An: FreeRadius users mailing list > Betreff: Re: echo module creating zombies > steff...@gmx.de wrote: > > These are versions 2.1.9 and 2.2.0. > > It may happen from time to time that a zombie child appears. But they > will get cleaned up when the server receives more packets. > > If you get *many* zombies, it's a problem. But one for 2-3 seconds > isn't an issue. Ok... I'm somewhere in between many and short time zombies with version 2.2.0 - there is one zombie that stays until the next request and gets then replaced by the next zombie. Regards Stephan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: echo module creating zombies
Original-Nachricht > Datum: Wed, 20 Feb 2013 10:59:14 -0500 > Von: Alan DeKok > An: FreeRadius users mailing list > Betreff: Re: echo module creating zombies > steff...@gmx.de wrote: > > I have a problem regarding the echo module which on my system creates > zombie processes. I am using the following settings for echo: > > > > wait = no > > program = "/bin/true" (just for testing purposes) > > packet_type = Access-Accept > > > > After echo execs the program in question there is an undead child > process left behind: > > Which version is this? There was one version (IIRC) which had this > issue. But recent ones don't. These are versions 2.1.9 and 2.2.0. Regards Stephan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: echo module creating zombies
Original-Nachricht > Datum: Wed, 20 Feb 2013 10:29:07 -0500 > Von: "Craig Campbell" > An: "FreeRadius users mailing list" > Betreff: Re: echo module creating zombies > Try changing wait to "yes". > > Zombies are processes that have ended, but for which the parent has not > "waited" to acknowledge the death of the child. > Their 'slot' in the process table has not been freed for re-use. > > -Original Message- > From: steff...@gmx.de > Sent: Wednesday, February 20, 2013 9:54 AM > To: freeradius-users@lists.freeradius.org > Subject: echo module creating zombies > > Hello list, > > I have a problem regarding the echo module which on my system creates > zombie > processes. I am using the following settings for echo: > > wait = no > program = "/bin/true" (just for testing purposes) > packet_type = Access-Accept > > After echo execs the program in question there is an undead child process > left behind: > > 13467 ?Ssl0:00 /usr/local/freeradius/sbin/radiusd > 14258 ?Z 0:00 \_ [true] Ah, okay, thanks. I deliberately set wait=no since I don't want the module to fail just because the underlying binary exited with something else than 0. I just need to run a script and pass it the username after a successful login, is there a better way to do this ? The exec module doesn't seem the right way to to this. Regards Stephan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
echo module creating zombies
Hello list,
I have a problem regarding the echo module which on my system creates zombie
processes. I am using the following settings for echo:
wait = no
program = "/bin/true" (just for testing purposes)
packet_type = Access-Accept
After echo execs the program in question there is an undead child process left
behind:
13467 ?Ssl0:00 /usr/local/freeradius/sbin/radiusd
14258 ?Z 0:00 \_ [true]
This is pretty much everything strace has to say:
14258 execve("/bin/true", ["/bin/true", "asdf"], [/* 6 vars */]) = 0
14258 brk(0)= 0x85c6000
14258 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7787000
14258 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
14258 open("/etc/ld.so.cache", O_RDONLY) = 3
14258 fstat64(3, {st_mode=S_IFREG|0644, st_size=67227, ...}) = 0
14258 mmap2(NULL, 67227, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7776000
14258 close(3) = 0
14258 open("/lib/i686/libc.so.6", O_RDONLY) = 3
14258 read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0h\1\0004\0\0\0\320\366\24\0\0\0\0\0004\0
\0\n\0(\0D\0C\0\6\0\0\0004\0\0\0004\0\0\0004\0\0\0@\1\0\0@\1\0\0\5\0\0\0\4\0\0\0\3\0\0\0`z\23\0`z\23\0`z\23\0\23\0\0\0\23\0\0\0\4\0\0\0\1\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0P\272\24\0P\272\24\0\5\0\0\0\0\20\0\0\1\0\0\0\344\301\24\0\344\301\24\0\344\301\24\0\230'\0\0lT\0\0\6\0\0\0\0\20\0\0\2\0\0\0|\335\24\0|\335\24\0|\335\24\0\360\0\0\0\360\0\0\0\6\0\0\0\4\0\0\0\4\0\0\0t\1\0\0t\1\0\0t\1\0\0
\0\0\0
\0\0\0\4\0\0\0\4\0\0\0\7\0\0\0\344\301\24\0\344\301\24\0\344\301\24\0\10\0\0\0@\0\0\0\4\0\0\0\4\0\0\0P\345tdtz\23\0tz\23\0tz\23\0\314+\0\0\314+\0\0\4\0\0\0\4\0\0\0Q\345td\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\4\0\0\0R\345td\344\301\24\0\344\301\24\0\344\301\24\0\34\36\0\0\34\36\0\0\4\0\0\0\1\0\0\0\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0\t\0\0\0\363\3\0\0\t\0\0\0\0\2\0\0\16\0\0\0\2400\20D\200
\2\1\214\3\346\220AE\210\0\204\0\10\0A\200\0@\300\200\0\f\2\f\0!
\0010\0\10@\"\10\246\4\210H6l\240\0260\0&\204\200\216\4\10B$\2\f\246\244\32\6c\310\0\302
\1\300\0R\0!\201\10\4\n \250\24\0\24(`\0\0P\240\312DB", 512) = 512
14258 fstat64(3, {st_mode=S_IFREG|0755, st_size=1376624, ...}) = 0
14258 mmap2(NULL, 1381968, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0xb7624000
14258 mmap2(0xb777, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14c) = 0xb777
14258 mmap2(0xb7773000, 9808, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7773000
14258 close(3) = 0
14258 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7623000
14258 set_thread_area({entry_number:-1 -> 6, base_addr:0xb76236c0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
14258 mprotect(0xb777, 8192, PROT_READ) = 0
14258 mprotect(0x804f000, 4096, PROT_READ) = 0
14258 mprotect(0xb77a3000, 4096, PROT_READ) = 0
14258 munmap(0xb7776000, 67227) = 0
14258 brk(0)= 0x85c6000
14258 brk(0x85e7000)= 0x85e7000
14258 close(1) = 0
14258 close(2) = 0
14258 exit_group(0) = ?
Any ideas why the zombies occur ?
Thanks
Stephan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
dot1x with samba workstation accounts part two
Hi list,
I am new here and would like to respond to a message which has been sent before
I was subscribed:
https://lists.freeradius.org/pipermail/freeradius-users/2010-June/msg00432.html
I ran into the same problem and might have a solution that satisfies both
sides, I added a configuration option to modules/mschap which is called
"enforce_user_flag". With this patch the following happens:
If the disabled flag is set, it rejects anyway.
If the enforce_user_flag is not set or set to 'yes', mschap checks for the
presence of the user flag (this has been the behaviour so far).
If enforce_user_flag is set to 'no', mschap checks for the presence of the
„workstation trust account“ „server trust account“ or „normal user account“.
If one of them is present it is satisfied with the flags.
With this solution mschap behaves like it did before with out of the box
settings but is able to honor the workstation or server trust account flags if
the configuration option is set accordingly. There would be no need to disable
the check of the 'disabled' flag.
It is probably not the best code ever but maybe it helps someone.
Regards
Stephan
--- freeradius-server-2.1.10-original/src/modules/rlm_mschap/rlm_mschap.c 2010-09-28 13:03:56.0 +0200
+++ freeradius-server-2.1.10-patched/src/modules/rlm_mschap/rlm_mschap.c 2010-11-02 13:01:05.681040758 +0100
@@ -133,6 +133,7 @@
int require_encryption;
int require_strong;
int with_ntdomain_hack; /* this should be in another module */
+ int enforce_user_flag;
char *passwd_file;
const char *xlat_name;
char *ntlm_auth;
@@ -530,6 +531,8 @@
offsetof(rlm_mschap_t,require_strong), NULL, "no" },
{ "with_ntdomain_hack", PW_TYPE_BOOLEAN,
offsetof(rlm_mschap_t,with_ntdomain_hack), NULL, "no" },
+ { "enforce_user_flag",PW_TYPE_BOOLEAN,
+ offsetof(rlm_mschap_t,enforce_user_flag), NULL, "yes" },
{ "passwd", PW_TYPE_STRING_PTR,
offsetof(rlm_mschap_t, passwd_file), NULL, NULL },
{ "ntlm_auth", PW_TYPE_STRING_PTR,
@@ -951,6 +954,7 @@
char *username_string;
int chap = 0;
int do_ntlm_auth;
+ int bad_account_flags = 0;
/*
* If we have ntlm_auth configured, use it unless told
@@ -1267,14 +1271,31 @@
*/
if (smb_ctrl) {
/*
- * Account is disabled.
+ * Account could be disabled or lack the right flags.
*
- * They're found, but they don't exist, so we
+ * They're found, but do not meet the requirements, so we
* return 'not found'.
*/
- if (((smb_ctrl->vp_integer & ACB_DISABLED) != 0) ||
- ((smb_ctrl->vp_integer & ACB_NORMAL) == 0)) {
- RDEBUG2("SMB-Account-Ctrl says that the account is disabled, or is not a normal account.");
+ if ((smb_ctrl->vp_integer & ACB_DISABLED) != 0) {
+ RDEBUG2("SMB-Account-Ctrl says that the account is disabled. Rejecting.");
+ bad_account_flags=1;
+ } else {
+
+ if (inst->enforce_user_flag) {
+RDEBUG2("enforce_user_flag is set, account needs to be a user account ('U' flag set)");
+if ((smb_ctrl->vp_integer & ACB_NORMAL) == 0) {
+ RDEBUG2("SMB-Account-Ctrl says that the account is not a normal user account.");
+ bad_account_flags=1;
+}
+ } else {
+RDEBUG2("enforce_user_flag is not set, workstation/server trust accounts are ok as are user accounts ('W' 'S' or 'U' flag set)");
+if (((smb_ctrl->vp_integer & ACB_WSTRUST) == 0) && ((smb_ctrl->vp_integer & ACB_SVRTRUST) == 0) && ((smb_ctrl->vp_integer & ACB_NORMAL) == 0)) {
+ RDEBUG2("SMB-Account-Ctrl says that the account is neither a workstation nor a server trust account. Rejecting.");
+ bad_account_flags=1;
+}
+ }
+ }
+ if (bad_account_flags==1) {
mschap_add_reply(request, &request->reply->vps,
*response->vp_octets,
"MS-CHAP-Error", "E=691 R=1", 9);
--- freeradius-server-2.1.10-original/raddb/modules/mschap 2010-09-28 13:03:56.0 +0200
+++ freeradius-server-2.1.10-patched/raddb/modules/mschap 2010-11-02 11:52:56.057045961 +0100
@@ -35,6 +35,12 @@
#
#with_ntdomain_hack = no
+ # If you are using machine authentication with
+ # samba and ldap you might want to set this to
+ # "no" so the samba object for the machine does
+ # not need to have the user flag set.
+ # enforce_user_flag = yes
+
# The module can perform authentication itself, OR
# use a Windows Domain Controller. This configuration
# directive tells the module to call the ntlm_auth
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
