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

[Axel Thimm]

On Wed, Sep 21, 2005 at 02:46:17PM -0700, Jeremy Allison wrote:
> 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 ?

This is RHEL4 on x86_64.

On Wed, Sep 21, 2005 at 03:00:44PM -0700, Jeremy Allison wrote:
> Can you run this test program on your system to check the behaviour ?
> This program runs correctly on SuSE Linux 9.3 and Fedora Core 2.
> 
> If it doesn't run I think it may be a bug on your UNIX.

I tested it and it runs successfully.

Is there a chance that the fd isn't opened by root in
set_delete_on_close?

Thanks!
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba/attachments/20050922/1dd008b1/attachment.bin