Gencache fails to open gencache.tdb
Hi all!
Attached patch can be seen as proposal to discuss behavior of gencache in
case when it is used in applications running under non-priviledged
accounts so that O_RDWR|O_CREAT always fails against system-wide
lock_path(gencache.tdb) (which is usually created by smbd/nmbd).
The patch adds error resistence and tries to re-open gencache.tdb in
O_RDONLY mode if O_RDWR|O_CREAT failed. This allows the application to use
existing entries but forbids cache updates.
Simo proposed to have per-account gencache.tdb in such case
(~/.smb/gencache.tdb?) but I'm not sure it is good to put such behavior
into the level where gencache exists (lib/). Any other thoughts?
--
/ Alexander Bokovoy
---
It's not reality or how you perceive things that's important -- it's
what you're taking for it...
--- samba-3.0.tag/source/lib/gencache.c.orig_alt2003-01-27 22:02:24 +0200
+++ samba-3.0.tag/source/lib/gencache.c 2003-02-05 18:24:06 +0200
@@ -28,9 +28,13 @@
#define TIMEOUT_LEN 12
#define CACHE_DATA_FMT %12u/%s
+typedef enum {
+GENCACHE_RDRW,
+GENCACHE_RDONLY
+} gencache_access_t;
static TDB_CONTEXT *cache;
-
+static gencache_access_t cache_type;
/**
* @file gencache.c
* @brief Generic, persistent and shared between processes cache mechanism
@@ -64,6 +68,15 @@
cache = tdb_open_log(cache_fname, 0, TDB_DEFAULT,
O_RDWR|O_CREAT, 0644);
+cache_type = GENCACHE_RDRW;
+
+if (!cache) {
+ DEBUG(5, (Opening cache file at %s in read-write mode failed, try to
+open it read-only\n,
+ cache_fname));
+ cache = tdb_open_log(cache_fname, 0, TDB_DEFAULT,
+O_RDONLY, 0644);
+cache_type = GENCACHE_RDONLY;
+}
SAFE_FREE(cache_fname);
if (!cache) {
@@ -111,7 +124,7 @@
/* fail completely if get null pointers passed */
SMB_ASSERT(keystr value);
- if (!gencache_init()) return False;
+ if (!gencache_init() || (cache_type == GENCACHE_RDONLY)) return False;
asprintf(valstr, CACHE_DATA_FMT, (int)timeout, value);
keybuf.dptr = strdup(keystr);
@@ -152,7 +165,7 @@
/* fail completely if get null pointers passed */
SMB_ASSERT(keystr valstr);
- if (!gencache_init()) return False;
+ if (!gencache_init() || (cache_type == GENCACHE_RDONLY)) return False;
/*
* Check whether entry exists in the cache
@@ -203,7 +216,7 @@
/* fail completely if get null pointers passed */
SMB_ASSERT(keystr);
- if (!gencache_init()) return False;
+ if (!gencache_init() || (cache_type == GENCACHE_RDONLY)) return False;
keybuf.dptr = strdup(keystr);
keybuf.dsize = strlen(keystr);
Re: Gencache fails to open gencache.tdb
On Wed, Feb 05, 2003 at 08:01:51PM +0200, Alexander Bokovoy wrote: Hi all! Attached patch can be seen as proposal to discuss behavior of gencache in case when it is used in applications running under non-priviledged accounts so that O_RDWR|O_CREAT always fails against system-wide lock_path(gencache.tdb) (which is usually created by smbd/nmbd). The patch adds error resistence and tries to re-open gencache.tdb in O_RDONLY mode if O_RDWR|O_CREAT failed. This allows the application to use existing entries but forbids cache updates. I understand your idea, but it's useful only when another root-privileged process is able to update the cache contents (like parent process ?). Otherwise, only per-user cache makes sense when it comes to being useful. Simo proposed to have per-account gencache.tdb in such case (~/.smb/gencache.tdb?) but I'm not sure it is good to put such behavior into the level where gencache exists (lib/). Any other thoughts? Look above. The other question is what do we expect non-privileged account to be able to do with samba daemons ? -- cheers, ++ |Rafal 'Mimir' Szczesniak [EMAIL PROTECTED] | |*BSD, GNU/Linux and Samba / |__/
Re: Gencache fails to open gencache.tdb
On Thu, Feb 06, 2003 at 12:06:04AM +0100, Rafal Szczesniak wrote: Attached patch can be seen as proposal to discuss behavior of gencache in case when it is used in applications running under non-priviledged accounts so that O_RDWR|O_CREAT always fails against system-wide lock_path(gencache.tdb) (which is usually created by smbd/nmbd). The patch adds error resistence and tries to re-open gencache.tdb in O_RDONLY mode if O_RDWR|O_CREAT failed. This allows the application to use existing entries but forbids cache updates. I understand your idea, but it's useful only when another root-privileged process is able to update the cache contents (like parent process ?). Otherwise, only per-user cache makes sense when it comes to being useful. It is actually slightly useful. If you are a user process running on a Samba server, then you can share the up to date cache data that is generated by smbd and nmbd. You're right though in the fact that you can't update it or expire old entries. I still think it's useful though. Tim.
Re: Gencache fails to open gencache.tdb
On Thu, 2003-02-06 at 10:10, Tim Potter wrote: On Thu, Feb 06, 2003 at 12:06:04AM +0100, Rafal Szczesniak wrote: Attached patch can be seen as proposal to discuss behavior of gencache in case when it is used in applications running under non-priviledged accounts so that O_RDWR|O_CREAT always fails against system-wide lock_path(gencache.tdb) (which is usually created by smbd/nmbd). The patch adds error resistence and tries to re-open gencache.tdb in O_RDONLY mode if O_RDWR|O_CREAT failed. This allows the application to use existing entries but forbids cache updates. I understand your idea, but it's useful only when another root-privileged process is able to update the cache contents (like parent process ?). Otherwise, only per-user cache makes sense when it comes to being useful. It is actually slightly useful. If you are a user process running on a Samba server, then you can share the up to date cache data that is generated by smbd and nmbd. You're right though in the fact that you can't update it or expire old entries. I still think it's useful though. One of the problems is that gencache can be used to store all sorts of information. For example I want to move netlogon_unigroup.tdb into it, and possibly more sensitive information in future. My worry is that we could leak information this way. I'm also told that there could be issues with the ability to 'block' smbd with byte-range read-locking on that database. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net signature.asc Description: This is a digitally signed message part
Re: Gencache fails to open gencache.tdb
On Thu, Feb 06, 2003 at 05:46:46PM +1100, Andrew Bartlett wrote: On Thu, 2003-02-06 at 10:10, Tim Potter wrote: On Thu, Feb 06, 2003 at 12:06:04AM +0100, Rafal Szczesniak wrote: Attached patch can be seen as proposal to discuss behavior of gencache in case when it is used in applications running under non-priviledged accounts so that O_RDWR|O_CREAT always fails against system-wide lock_path(gencache.tdb) (which is usually created by smbd/nmbd). The patch adds error resistence and tries to re-open gencache.tdb in O_RDONLY mode if O_RDWR|O_CREAT failed. This allows the application to use existing entries but forbids cache updates. I understand your idea, but it's useful only when another root-privileged process is able to update the cache contents (like parent process ?). Otherwise, only per-user cache makes sense when it comes to being useful. It is actually slightly useful. If you are a user process running on a Samba server, then you can share the up to date cache data that is generated by smbd and nmbd. You're right though in the fact that you can't update it or expire old entries. I still think it's useful though. One of the problems is that gencache can be used to store all sorts of information. For example I want to move netlogon_unigroup.tdb into it, and possibly more sensitive information in future. Exactly. And implementing a sort of access control is far too much for such simple mechanism. My worry is that we could leak information this way. I'm also told that there could be issues with the ability to 'block' smbd with byte-range read-locking on that database. You mean the process that does read from gencache.tdb file could block it and thus prevent from writing to this particular byte-range ? -- cheers, ++ |Rafal 'Mimir' Szczesniak [EMAIL PROTECTED] | |*BSD, GNU/Linux and Samba / |__/
