[Samba] locking.tdb: expand_file ftruncate to 8192 failed (Permission denied)

[Jeremy Allison]

On Wed, Sep 21, 2005 at 09:01:10PM +0200, Axel Thimm wrote:
> Hi,
> 
> I'm hunting a bug in 3.0.x (tested on 3.0.10 and 3.0.20). Users can
> create and modfy files, but cannot delete them. The logs show
> 
> [2005/09/21 20:48:14, 0, pid=18388, effective(4019, 412), real(4019, 0)] tdb/tdbutil.c:tdb_log(767)
>   tdb(/srv/physik.fu-berlin.de/data/.samba/cluster1-test/cache/locking.tdb): expand_file ftruncate to 8192 failed (Permission denied)
> [2005/09/21 20:48:15, 0, pid=18388, effective(4019, 412), real(4019, 0)] tdb/tdbutil.c:tdb_log(767)
>   tdb(/srv/physik.fu-berlin.de/data/.samba/cluster1-test/cache/locking.tdb): expand_file ftruncate to 8192 failed (Permission denied)
> [2005/09/21 20:48:15, 0, pid=18388, effective(4019, 412), real(4019, 0)] smbd/trans2.c:set_delete_on_close(3533)
>   set_delete_on_close: failed to change delete on close flag for file testspampure~
> 
> Turning on more debugging one sees that set_delete_on_close returns
> NT_STATUS_ACCESS_DENIED. According to the code in 3.0.20 this is
> because lock_share_entry_fsp(fsp) returned False. At the time
> locking.tdb is being tried to be expanded and later used for locking,
> smbd has already become the user and has no permissions to perform the
> tasks.
> 
> The (ugly) workarround is to make locking.tdb 0666. I've seen similar
> reports in google w/o any resolution. Shouldn't expand_file be called
> as root?
> 
> Is this a buggy code path only some configs lead to? What configs are
> these, and how can I avoid them? :)
> 
> I can offer more detailed debug logs, if needed. Thanks!
> 
> NTSTATUS set_delete_on_close(files_struct *fsp, BOOL delete_on_close)
> {
>         DEBUG(10,("set_delete_on_close: %s delete on close flag for "
>                   "fnum = %d, file %s\n",
>                   delete_on_close ? "Adding" : "Removing", fsp->fnum,
>                   fsp->fsp_name ));
> 
>         if (fsp->is_directory || fsp->is_stat)
>                 return NT_STATUS_OK;
> 
>         if (lock_share_entry_fsp(fsp) == False)
>                 return NT_STATUS_ACCESS_DENIED;

Very interesting - we assume that once we have the fd open as root we
have permissions to expand the file at will..... What platform are you
running this on ?

Jeremy.