System documentation of Samba
One of our servers crashed and when we booted it again one Samba process hung and grabbed one of the servers cpu's. When we killed the samba process, another process generated 100% load on one cpu. From the log file: smbd/open.c:open_mode_check(555) open_mode_check: exlusive oplock left by process 23227 after break ! For file profile/.../office.file.doc, dev = 900, inode = 2704003. Deleting it to continue... lib/util.c:smb_panic(1055) PANIC: open_mode_check: Existant process 23227 left active oplock. We tried to disable oplocks but no luck. After some more testing we deleted all files in /var/opt/samba/lock (brlock.tdbconnections.tdb messages.tdb ntdrivers.tdb ntprinters.tdb share_info.tdb unexpected.tdb browse.datlocking.tdb ntforms.tdb printing.tdb ) and restarted samba. This time it worked fine. Is there som information about the tdb file and the inner structures of Samba? What do we lose if we delete the diffrent tdb files? We are using Samba 2.2.2 Regards, Johannes -- SGU - Sveriges Geologiska Undersökning Johannes Tyve Sysadmin +46-18-17 92 21 --
RE: ldap
Looks like there was a Samba regression just prior to 2.2.5 which causes OS/2 clients to fail in very strange ways since EA buffers (EAOP2 structs i.e. level 2 SetFileInfo buffers) are now treated as FILESTATUS3 buffers (see below). http://cvs.samba.org/cgi-bin/cvsweb/samba/source/smbd/trans2.c.dif f?r1=1.149.4.16.2.8r2=1.149.4.16.2.9f=h Anyone know why the EAS_NOT_SUPPORTED check was pulled out at around line 2400 of smbd/trans2.c? See my bugreport at http://bugs.samba.org/?findid=22128 Samba needs to know more about the EA request to determine if it is an EA request to reject and not a file allocation info set call. --- Michel Stoop, Senior Network and Systems Administrator postmaster for ncg.nl, ccggron.nl and centralindustrygroup.com Numeriek Centrum Groningen B.V. Shipbuilding Services Postbus 204 9700AE Groningen +31 (0)50 541 26 32 fax: +31 (0)50 542 37 17 http://www.ncg.nl mailto:[EMAIL PROTECTED] ---
initial gencache implementation
This is first implementation of caching mechanism. It includes
both lib/gencache.c code and utils/net_cache.c as command-line
control/testing tool.
comments are welcome
--
cheers,
++
|Rafal 'Mimir' Szczesniak [EMAIL PROTECTED] |
|*BSD, GNU/Linux and Samba /
|__/
Index: Makefile.in
===
RCS file: /cvsroot/samba/source/Makefile.in,v
retrieving revision 1.527
diff -u -r1.527 Makefile.in
--- Makefile.in 30 Aug 2002 12:46:54 - 1.527
+++ Makefile.in 5 Sep 2002 10:08:12 -
@@ -139,7 +139,7 @@
lib/md5.o lib/hmacmd5.o lib/iconv.o lib/smbpasswd.o \
nsswitch/wb_client.o nsswitch/wb_common.o \
lib/pam_errors.o intl/lang_tdb.o lib/account_pol.o \
- lib/adt_tree.o lib/popt_common.o $(TDB_OBJ)
+ lib/adt_tree.o lib/popt_common.o lib/gencache.o $(TDB_OBJ)
LIB_SMBD_OBJ = lib/system_smbd.o lib/util_smbd.o
@@ -242,7 +242,8 @@
AUTH_OBJ = auth/auth.o auth/auth_sam.o auth/auth_server.o auth/auth_domain.o \
auth/auth_rhosts.o auth/auth_unix.o auth/auth_util.o auth/auth_winbind.o \
- auth/auth_builtin.o auth/auth_compat.o $(PLAINTEXT_AUTH_OBJ) $(UNIGRP_OBJ)
+ auth/auth_builtin.o auth/auth_compat.o \
+ $(PLAINTEXT_AUTH_OBJ) $(UNIGRP_OBJ)
MANGLE_OBJ = smbd/mangle.o smbd/mangle_hash.o smbd/mangle_map.o smbd/mangle_hash2.o
@@ -381,7 +382,8 @@
NET_OBJ1 = utils/net.o utils/net_ads.o utils/net_ads_cldap.o utils/net_help.o \
utils/net_rap.o utils/net_rpc.o utils/net_rpc_samsync.o \
- utils/net_rpc_join.o utils/net_time.o utils/net_lookup.o
+ utils/net_rpc_join.o utils/net_time.o utils/net_lookup.o \
+ utils/net_cache.o
NET_OBJ = $(NET_OBJ1) $(SECRETS_OBJ) $(LIBSMB_OBJ) \
$(RPC_PARSE_OBJ) $(PASSDB_GET_SET_OBJ) \
/*
Unix SMB/CIFS implementation.
Generic, persistent and shared between processes cache mechanism for use
by various parts of the Samba code
Copyright (C) Rafal Szczesniak2002
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#include includes.h
#undef DBGC_CLASS
#define DBGC_CLASS DBGC_TDB
#define TIMEOUT_LEN 12
#define CACHE_DATA_FMT %12d; %s
static TDB_CONTEXT *cache;
/**
* @file gencache.c
* @brief Generic, persistent and shared between processes cache mechanism
*for use by various parts of the Samba code
*
**/
/**
* Cache initialisation function. Opens cache tdb file or creates
* it if does not exist.
*
* @return true on successful initialisation of the cache or
* false on failure
**/
BOOL gencache_init(void)
{
char* cache_fname;
/* skip file open if it's already opened */
if (cache) return True;
asprintf(cache_fname, %s/%s, lp_lockdir(), gencache.tdb);
DEBUG(5, (Opening cache file at %s\n, cache_fname));
cache = tdb_open_log(cache_fname, 0, TDB_DEFAULT,
O_RDWR|O_CREAT, 0644);
if (!cache) {
DEBUG(0, (Attempt to open the cache file has failed.\n));
return False;
}
return True;
}
/**
* Cache shutdown function. Closes opened cache tdb file.
*
* @return true on successful closing the cache or
* false on failure during cache shutdown
**/
BOOL gencache_shutdown(void)
{
/* tdb_close routine returns 0 on successful close */
if (!cache) return False;
DEBUG(5, (Closing cache file\n));
return tdb_close(cache) ? False : True;
}
/**
* Add one entry to the cache file.
* (it part of tridge's proposed API)
*
* @param key string that represents a key of this entry
* @param value text representation value being cached
* @param timeout time when the value is expired
*
* @return true when entry is successfuly stored or
* false on the attempt's failure
**/
BOOL gencache_add(const char *keystr, const char *value, time_t timeout)
{
int ret;
TDB_DATA keybuf, databuf;
char* valstr = NULL;
if (!gencache_init()) return False;
asprintf(valstr, CACHE_DATA_FMT, (int)timeout, value);
keybuf.dptr = strdup(keystr);
keybuf.dsize = strlen(keystr);
databuf.dptr = strdup(valstr);
databuf.dsize = strlen(valstr);
DEBUG(10, (Adding cache entry with key = %s; value = %s and timeout
Re: System documentation of Samba
On Thu, Sep 05, 2002 at 08:59:36AM +0200, Johannes Tyve wrote: One of our servers crashed and when we booted it again one Samba process hung and grabbed one of the servers cpu's. When we killed the samba process, another process generated 100% load on one cpu. From the log file: smbd/open.c:open_mode_check(555) open_mode_check: exlusive oplock left by process 23227 after break ! For file profile/.../office.file.doc, dev = 900, inode = 2704003. Deleting it to continue... lib/util.c:smb_panic(1055) PANIC: open_mode_check: Existant process 23227 left active oplock. We tried to disable oplocks but no luck. After some more testing we deleted all files in /var/opt/samba/lock (brlock.tdb connections.tdb messages.tdb ntdrivers.tdbntprinters.tdb share_info.tdb unexpected.tdb browse.dat locking.tdb ntforms.tdb printing.tdb ) and restarted samba. This time it worked fine. Is there som information about the tdb file and the inner structures of Samba? What do we lose if we delete the diffrent tdb files? We are using Samba 2.2.2 This was one of the problems we fixed after 2.2.2. I would recommend upgrading to 2.2.5. However there are still some scaling problems with Solaris, we are awaiting confirmation of a Sun hotfix on the issue (it's a Solaris bug now, not a Samba one). Jeremy.
Re: System documentation of Samba
Date: Thu, 5 Sep 2002 13:14:41 + From: [EMAIL PROTECTED] To: Johannes Tyve [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: System documentation of Samba On Thu, Sep 05, 2002 at 08:59:36AM +0200, Johannes Tyve wrote: One of our servers crashed and when we booted it again one Samba process hung and grabbed one of the servers cpu's. When we killed the samba process, another process generated 100% load on one cpu. From the log file: smbd/open.c:open_mode_check(555) open_mode_check: exlusive oplock left by process 23227 after break ! For file profile/.../office.file.doc, dev = 900, inode = 2704003. Deleting it to continue... lib/util.c:smb_panic(1055) PANIC: open_mode_check: Existant process 23227 left active oplock. We tried to disable oplocks but no luck. After some more testing we deleted all files in /var/opt/samba/lock (brlock.tdb connections.tdb messages.tdb ntdrivers.tdbntprinters.tdb share_info.tdb unexpected.tdb browse.dat locking.tdb ntforms.tdb printing.tdb ) and restarted samba. This time it worked fine. Is there som information about the tdb file and the inner structures of Samba? What do we lose if we delete the diffrent tdb files? We are using Samba 2.2.2 This was one of the problems we fixed after 2.2.2. I would recommend upgrading to 2.2.5. However there are still some scaling problems with Solaris, we are awaiting confirmation of a Sun hotfix on the issue (it's a Solaris bug now, not a Samba one). Jeremy. Could you provide some details the bug in Solaris? 2.2.2 used to work fine for me, but recently it has fallen apart. 2.2.5 behaves the same. I can think of a recent jumbo patch cluster installation that might be to blame, but I'd like to know if it's possible to track it down a back it out for now. Jeff
with-pam and encrypted passwords
I have nss_ldap installed and would like to use it for samba.
As I have read from documetation: If I use encryted password , I can't
authenticate via pam?
Is this fact still correct?
If yes, would it be possible to implement some how?
Could I (or someone more talent) try to code something like:
(I assume that encrypted password are easily converted to text on
serverd side)
1. User send encrypted pasword to samba
2. Samba converts password to text, and check it agaists pam
if (smb_pam_passcheck) {
samba continues and stores needed lm and smb-hashes to local
smbpassword file
saves session information and continues
}
OR..
Could this be done on pam-side?
On above scenario, if pam will create/sync smbpasswd atomaticly when
login is done via nss_ldap.
Petri Asikainen
Re: SNIA CIFS Technical Reference 1.0
On Thu, 5 Sep 2002, Arnold Jones wrote: samba-technical, When we switched to a new web site the document for some reason did not make it. It is now at: http://www.snia.org/tech_activities/CIFS - Arnold Thanks. I've posted a note about this on Samba.org. :-) cheers, jerry
Re: msdfs referrals at share-level
Hi, Clients do request dfs referrals for every share they connect to. In a dfs reply for a share, you could try and send a different sharename and see what happens. I don't know if clients will be able to handle this. Look for self_referral in the setup_dfs_referral() code to find out where to start making changes. Let me know how the clients take it.. Thanks, Shirish - Original Message - From: Guenther Deschner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 04, 2002 2:48 PM Subject: msdfs referrals at share-level hello everybody, as far as i have looked into msdfs.c it seems to be impossible to send a client a dfs-referral at the share level (\\fileserver\msdfs-link). maybe there is another way to proxy a request to \\samba\thisshare to \\anothersamba\thatshare ? i currently want to migrate a couple of nt-servers transparently for clients. the basic idea is to setup one samba-server that offers faked file-service via netbios-aliases and dfs-redirects to the real samba-fileserver. unfortunatly touching the clients is a no-go. old setup with *nt*: client - //fileserver/share1 planned setup with *samba*: client - //fileserver/share1 where share1 - msdfs:samba-file\whatever any help is much appreciated. bye, guenther -- Guenther Deschner [EMAIL PROTECTED] SuSE Linux AGGnuPG: 8EE11688 Berliner Str. 27 phone: +49 (0) 30 / 430944778 D-13507 Berlin fax: +49 (0) 30 / 43732804
Re: System documentation of Samba
Jeff Mandel wrote: Could you provide some details the bug in Solaris? 2.2.2 used to work fine for me, but recently it has fallen apart. 2.2.5 behaves the same. I can think of a recent jumbo patch cluster installation that might be to blame, but I'd like to know if it's possible to track it down a back it out for now. Sure: it's a performance problem with locks which shows up when locking the index file of a dbm-style database (which have two files, an index and a data file), and which is being shared via Samba with PC clients. At least one site, and probably two, have the problem. I'm following it with considerable interest (I work for Sun, you see, although not on Samba (:-)) It doesn't affect the performance of Samba on Solaris in general, and oddly enough it doesn't seem to hit MS Access... open_mode_check: exlusive oplock left by process 23227 after break For file profile/.../office.file.doc, It's not related to the problem you see, with ordinary oplocked .doc files. One wouldn't oplock dbm files! --dave -- David Collier-Brown, | Always do right. This will gratify Performance Engineering | some people and astonish the rest. Americas Customer Engineering, | -- Mark Twain (905) 415-2849 | [EMAIL PROTECTED]
Re: System documentation of Samba
David Collier-Brown wrote: Jeff Mandel wrote: Could you provide some details the bug in Solaris? 2.2.2 used to work fine for me, but recently it has fallen apart. 2.2.5 behaves the same. I can think of a recent jumbo patch cluster installation that might be to blame, but I'd like to know if it's possible to track it down a back it out for now. Sure: it's a performance problem with locks which shows up when locking the index file of a dbm-style database (which have two files, an index and a data file), and which is being shared via Samba with PC clients. At least one site, and probably two, have the problem. I'm following it with considerable interest (I work for Sun, you see, although not on Samba (:-)) It doesn't affect the performance of Samba on Solaris in general, and oddly enough it doesn't seem to hit MS Access... open_mode_check: exlusive oplock left by process 23227 after break For file profile/.../office.file.doc, It's not related to the problem you see, with ordinary oplocked .doc files. One wouldn't oplock dbm files! --dave It sounds like there are two scenarios here: 1) Locking performance problems on dbm-style databases shared with PCs. (We're not using any of those) 2) Race conditions caused by ??? (We have problem with this big time - and the one I'm more concerned about) Is the solaris bug that causes CPU race that Jeremy was referring to one of locking on samba's own db files in var/locks? Jeff
Re: Samba bug with OS/2 EAs and FindFirst bug
The second fix (for checking must have search attributes on FindFirst/FindNext) worked (fixing opening files) but our testers found a third and I hope final major interoperability problem with OS/2 to Samba that shows up e.g. in Lotus 123 and a few other apps saving files with new names (Save As dialog). It looks like Windows servers (this works from OS/2 to Windows) and Samba servers differ in how they treat impicit wildcards. Comparing traces between the Windows and Samba cases shows up immediate differences in how Trans2FindFirst of a directory (e.g. \) is handled.With search attributes of 0, and a target of \, Windows returns all of the files (but not directories) in the root directory - Samba 2.2.5 returned file not found. I will do some experiments to see if this is the only issue. Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: [EMAIL PROTECTED]
Re: [PATCH] group control bits ....
- Original Message -
From: Stefan (metze) Metzmacher [EMAIL PROTECTED]
To: Jelmer Vernooij [EMAIL PROTECTED]; Andrew Bartlett
[EMAIL PROTECTED]; Kai Krueger [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, September 05, 2002 7:39 PM
Subject: [PATCH] group control bits
...
diff -Npur --exclude=CVS --exclude=*.bak --exclude=*.o --exclude=.#*
HEAD/examples/sam/sam_skel.c HEAD-fix/examples/sam/sam_skel.c
--- HEAD/examples/sam/sam_skel.c Sat Aug 31 15:36:26 2002
+++ HEAD-fix/examples/sam/sam_skel.c Thu Sep 5 19:37:18 2002
@@ -183,7 +183,7 @@ NTSTATUS sam_skel_enum_groupmembers(cons
}
-NTSTATUS sam_skel_get_groups_of_account(const struct sam_methods
*sam_method, const SAM_ACCOUNT_HANDLE *account, const uint32 type, uint32
*group_count, SAM_GROUP_ENUM **groups)
+NTSTATUS sam_skel_get_groups_of_sid(const struct sam_methods *sam_method,
const NT_USER_TOKEN *access_token, const DOM_SID **sids, const uint32 type,
uint32 *group_count, SAM_GROUP_ENUM **groups)
you forgott to change the const uint32 type to uint16 group_ctrl
{
DEBUG(0,(sam_skel: %s was called!\n,__FUNCTION__));
return NT_STATUS_NOT_IMPLEMENTED;
@@ -238,7 +238,7 @@ NTSTATUS sam_init(const SAM_CONTEXT *sam
(*sam_method)-sam_delete_member_from_group =
sam_skel_delete_member_from_group;
(*sam_method)-sam_enum_groupmembers = sam_skel_enum_groupmembers;
- (*sam_method)-sam_get_groups_of_account =
sam_skel_get_groups_of_account;
+ (*sam_method)-sam_get_groups_of_sid = sam_skel_get_groups_of_sid;
(*sam_method)-free_private_data = NULL;
Other than that, I think the patch is good and imho should be checked in if
it compiles.
Kai
gencache implementation
I forgot to send patch with net_cache's entrypoint.
--
cheers,
++
|Rafal 'Mimir' Szczesniak [EMAIL PROTECTED] |
|*BSD, GNU/Linux and Samba /
|__/
Index: utils/net.c
===
RCS file: /cvsroot/samba/source/utils/net.c,v
retrieving revision 1.56
diff -u -r1.56 net.c
--- utils/net.c 21 Aug 2002 19:39:38 - 1.56
+++ utils/net.c 5 Sep 2002 14:14:28 -
@@ -352,6 +352,7 @@
{TIME, net_time},
{LOOKUP, net_lookup},
{JOIN, net_join},
+ {CACHE, net_cache},
{HELP, net_help},
{NULL, NULL}
Index: utils/net_help.c
===
RCS file: /cvsroot/samba/source/utils/net_help.c,v
retrieving revision 1.7
diff -u -r1.7 net_help.c
--- utils/net_help.c25 Jun 2002 02:29:09 - 1.7
+++ utils/net_help.c5 Sep 2002 14:14:29 -
@@ -135,6 +135,7 @@
net user\t\tto manage users\n\
net group\t\tto manage groups\n\
net join\t\tto join a domain\n\
+ net cache\t\tto operate on cache tdb file\n\
\n\
net ads command\tto run ADS commands\n\
net rap command\tto run RAP (pre-RPC) commands\n\
lp_sam_backend
Hi Jelmer, Hi Andrew, Hi Stefan
I've started to code up some functions to parse the lp_sam_backend list and
create a sam_context from it. In contrast to the current implementation,
these functions can take a domain name per backend and pass it down to the
apropriate sam_init(). To create a maximum of flexibility, the domain name
is prefixed with D- and the module_params are prefixed with O-. This
allows to leave either of the two away or swapp them arround.
The smb.conf entery could look something like this:
sam backend = sam_moduleA:D-domainA:O-options_for_sam_moduleA
sam_moduleB:O-options_for_sam_moduleB:sup_options:D-domainB or
sam backend = sam_moduleA
Currently the entire checking for correctnes is still missing apart from
many other points. In addition the style is still terrible, but I wanted to
know if this is the right direction before I continue to put effort into it.
So any comments are welcome.
Kai
typedef struct sam_backend_entry {
char*module_name;
char*module_params;
char*domain_name;
DOM_SID *domain_sid;
} SAM_BACKEND_ENTRY;
static NTSTATUS make_backend_entry(SAM_BACKEND_ENTRY *backend_entry, char
*sam_backend_string)
{
char *tmp = NULL;
char *tmp_string = sam_backend_string;
BOOL allow_intermediate_colon = False;
if (sam_backend_string == NULL)
return NT_STATUS_INVALID_PARAMETER;
backend_entry-module_name = sam_backend_string;
while ((tmp = strchr(tmp_string,':')) != NULL) {
if (tmp[2] == '-') {
switch (tmp[1]) {
case 'D': {
*tmp = 0;
backend_entry-domain_name = tmp +
3;
allow_intermediate_colon = False;
break;
}
case 'O': {
*tmp = 0;
backend_entry-module_params = tmp +
3;
allow_intermediate_colon = True;
break;
}
default:
if (!allow_intermediate_colon) {
DEBUG(2,(make_backend_entry: Error\n));
return
NT_STATUS_INVALID_PARAMETER;
}
}
}
else if (!allow_intermediate_colon) {
DEBUG(2,(make_backend_entry: Error\n));
return NT_STATUS_INVALID_PARAMETER;
}
tmp_string = tmp + 1;
}
if (backend_entry-domain_name == NULL) {
DEBUG(5,(make_backend_entry: no domain was specified for
sam module %s. Useing default domain %s\n,
backend_entry-module_name, lp_workgroup()));
backend_entry-domain_name = lp_workgroup();
}
if
(!secrets_fetch_domain_sid(backend_entry-domain_name,backend_entry-domain_
sid)) {
DEBUG(2,(make_backend_entry: There is no SID stored for
domain %s. Creating a new one.\n,
backend_entry-domain_name));
/* FIXME */
}
return NT_STATUS_OK;
}
static NTSTATUS make_sam_methods_backend_entry(SAM_METHODS **methods,
SAM_CONTEXT *context, SAM_BACKEND_ENTRY *sam_backend_entry)
{
NTSTATUS nt_status = NT_STATUS_UNSUCCESSFUL;
int i;
DEBUG(5,(Attempting to find sam backend %s\n,
backend_entry-module_name));
for (i = 0; builtin_sam_init_functions[i].module_name; i++)
{
if (strequal(builtin_sam_init_functions[i].module_name,
backend_entry-module_name))
{
DEBUG(5,(Found sam backend %s (at pos %d)\n,
backend_entry-module_name, i));
nt_status =
builtin_sam_init_functions[i].init(context, methods,
backend_entry-domain_sid, backend_entry-module_params);
if (NT_STATUS_IS_OK(nt_status)) {
DEBUG(5,(sam backend %s has a valid
init\n, backend_entry-module_name));
} else {
DEBUG(2,(sam backend %s did not correctly
init (error was %s)\n,
backend_entry-module_name,
nt_errstr(nt_status)));
}
return nt_status;
break; /* unreached */
}
}
DEBUG(2,(could not find backend %s\n,
backend_entry-module_name));
return NT_STATUS_INVALID_PARAMETER;
}
NTSTATUS make_sam_context_from_conf(SAM_CONTEXT **context)
{
int i = 0;
SAM_METHODS *curmethods, *tmpmethods;
char
Possible bug for 'directory mask' param
Hello, When a directory is created with Windows (2000 sp3) and with smbclient, the permissions differ on the newly created directory. Example: smb.conf contains: directory mask = 0711 When smbclient creates the directory the permissions are as follows: drwx--x--x ...but when I use Windows (2000 sp3) the permissions are: drwxrw-rw- Samba version is 2.2.5 -- Gavin D. Nipper University of Oklahoma Department of Mathematics
Re: initial gencache implementation
On Thu, Sep 05, 2002 at 12:15:36PM +0200, Rafal Szczesniak wrote: This is first implementation of caching mechanism. It includes both lib/gencache.c code and utils/net_cache.c as command-line control/testing tool. comments are welcome Rafal, that looks pretty good. Since you ask, I do have a few comments. (-: You assume that any cached data will be in null terminated string format which is not always the case. This is just my personal opinion but I would prefer for gencache_set to crash if you pass it a NULL pointer for the key or value parameter. Returning false in this case only hides the error until further along in the execution path by which time it will be more difficult to track down the original error. Some other minor things: - memleak of cache_fname in gencache_init - memleak of keybuf.dptr in gencache_set I don't think you need to strdup the key before passing it to tdb_fetch in gencache_set. You can just use the passed in parameter. Tim.
Re: initial gencache implementation
On Fri, Sep 06, 2002 at 10:17:19AM +1000, Tim Potter wrote: On Thu, Sep 05, 2002 at 12:15:36PM +0200, Rafal Szczesniak wrote: This is first implementation of caching mechanism. It includes both lib/gencache.c code and utils/net_cache.c as command-line control/testing tool. comments are welcome Rafal, that looks pretty good. Since you ask, I do have a few comments. (-: You assume that any cached data will be in null terminated string format which is not always the case. I understand this is a design property - it's up to the caller to mess with structs etc. This keeps the cache simple, and allows for human inspection with 'net cache' etc. This is just my personal opinion but I would prefer for gencache_set to crash if you pass it a NULL pointer for the key or value parameter. Returning false in this case only hides the error until further along in the execution path by which time it will be more difficult to track down the original error. Agreed. Andrew Bartlett
Re: initial gencache implementation
On Fri, Sep 06, 2002 at 02:10:23AM +, [EMAIL PROTECTED] wrote: You assume that any cached data will be in null terminated string format which is not always the case. I understand this is a design property - it's up to the caller to mess with structs etc. This keeps the cache simple, and allows for human inspection with 'net cache' etc. OK - fair enough, I missed that bit. Tim.
GSSAPI Kerberos mechanism
Hi,
I think that this document is close to defining the format of KRB5
requests in GSSAPI/SPNEGO
draft-ietf-cat-iakerb-04.txt
It says that this is the format:
InitialContextToken ::=
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMechMechType
-- MechType is OBJECT IDENTIFIER
-- representing Kerberos V5
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific;
-- ASN.1 usage within innerContextToken
-- is not required
and that:
The innerContextToken consists of a 2-byte TOK_ID field (defined below),
followed by the Kerberos V5 KRB-AS-REQ, KRB-AS-REP, KRB-TGS-REQ, or
KRB-TGS-REP messages, as appropriate. The TOK_ID field shall be one of the
following values, to denote that the message is either a request to the
KDC or a response from the KDC.
Message TOK_ID
KRB-KDC-REQ 00 03
KRB-KDC-REP 01 03
This is very close to what we see. The actual TOK_IDs seem to be:
KRB-KDC-REQ 0x0001
KRB-KDC-REP 0x0002
KRB-ERROR0x0003
Regards
-
Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Re: GSSAPI Kerberos mechanism
I think that this document is close to defining the format of KRB5
requests in GSSAPI/SPNEGO
Alternatively, see The Kerberos Version 5 GSS-API Mechanism,
RFC 1964. There may be a WG update somewhere...
-- Luke
1.1. Context Establishment Tokens
Per RFC-1508, Appendix B, the initial context establishment token
will be enclosed within framing as follows:
InitialContextToken ::=
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMechMechType
-- MechType is OBJECT IDENTIFIER
-- representing Kerberos V5
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific;
-- ASN.1 usage within innerContextToken
-- is not required
}
The innerContextToken of the initial context token will consist of a
Kerberos V5 KRB_AP_REQ message, preceded by a two-byte token-id
(TOK_ID) field, which shall contain the value 01 00.
The above GSS-API framing shall be applied to all tokens emitted by
the Kerberos V5 GSS-API mechanism, including KRB_AP_REP, KRB_ERROR,
context-deletion, and per-message tokens, not just to the initial
token in a context establishment sequence. While not required by
RFC-1508, this enables implementations to perform enhanced error-
checking. The innerContextToken field of context establishment tokens
for the Kerberos V5 GSS-API mechanism will contain a Kerberos message
(KRB_AP_REQ, KRB_AP_REP or KRB_ERROR), preceded by a 2-byte TOK_ID
field containing 01 00 for KRB_AP_REQ messages, 02 00 for KRB_AP_REP
messages and 03 00 for KRB_ERROR messages.
--
Luke Howard | lukehoward.com
PADL Software | www.padl.com
Re: GSSAPI Kerberos mechanism
On Fri, 6 Sep 2002, Luke Howard wrote:
I think that this document is close to defining the format of KRB5
requests in GSSAPI/SPNEGO
OK, that is the definition we are seeing. Thanks for that.
I have committed patches to Ethereal to dissect that, and I now need to
fix the kerberos 5 dissector so that the AP-REQ, AP-REP and KRB-ERROR can
be dissected separately from the whole of Kerberos itself.
Alternatively, see The Kerberos Version 5 GSS-API Mechanism,
RFC 1964. There may be a WG update somewhere...
-- Luke
1.1. Context Establishment Tokens
Per RFC-1508, Appendix B, the initial context establishment token
will be enclosed within framing as follows:
InitialContextToken ::=
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMechMechType
-- MechType is OBJECT IDENTIFIER
-- representing Kerberos V5
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific;
-- ASN.1 usage within innerContextToken
-- is not required
}
The innerContextToken of the initial context token will consist of a
Kerberos V5 KRB_AP_REQ message, preceded by a two-byte token-id
(TOK_ID) field, which shall contain the value 01 00.
The above GSS-API framing shall be applied to all tokens emitted by
the Kerberos V5 GSS-API mechanism, including KRB_AP_REP, KRB_ERROR,
context-deletion, and per-message tokens, not just to the initial
token in a context establishment sequence. While not required by
RFC-1508, this enables implementations to perform enhanced error-
checking. The innerContextToken field of context establishment tokens
for the Kerberos V5 GSS-API mechanism will contain a Kerberos message
(KRB_AP_REQ, KRB_AP_REP or KRB_ERROR), preceded by a 2-byte TOK_ID
field containing 01 00 for KRB_AP_REQ messages, 02 00 for KRB_AP_REP
messages and 03 00 for KRB_ERROR messages.
--
Luke Howard | lukehoward.com
PADL Software | www.padl.com
--
Regards
-
Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
