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

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