samba - Sep 2005 - locking.tdb: expand_file ftruncate to 8192 failed (Permission denied)

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;


-- 
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/20050921/887ee8c1/attachment.bin

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.

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;
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.

Jeremy.
-------------- next part --------------
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>
#include <pwd.h>

void become_user_permanently(const char *user)
{
	struct passwd *pw = getpwnam(user);

	if (!pw) {
		fprintf(stderr, "Can't get pw for %s\n", user);
		exit(1);
	}

        setresgid(pw->pw_gid,pw->pw_gid,pw->pw_gid);
        setgid(pw->pw_gid);
        setresuid(pw->pw_uid,pw->pw_uid,pw->pw_uid);
        setuid(pw->pw_uid);
	if (geteuid() != pw->pw_uid) {
		fprintf(stderr, "Can't become user %s\n", user);
		exit(1);
	}
}

int main(int argc, char **argv)
{
	struct stat st;
	int fd = open(argv[1], O_RDWR, 0600);
	uid_t uid = geteuid();
	
	if (argc != 3) {
		fprintf(stderr, "Usage: %s file username\n", argv[0]);
		return 1;
	}

	if (uid != 0) {
		fprintf(stderr, "%s must be run as root\n", argv[0]);
		return 1;
	}

	if (!fd) {
		return 1;
	}

	/* Now lose all privilages. */
	become_user_permanently(argv[2]);
	if (fstat(fd, &st) == -1) {
		return 1;
	}

	if (ftruncate(fd, st.st_size + 1024) == -1) {
		fprintf(stderr, "failed to extend file %s - error %s\n",
			argv[1], strerror(errno) );
		return 1;
	} else {
		printf("successfully extended file %s\n", argv[1]);
	}
	return 0;
}