lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 11 May 2009 11:46:15 +0900
From:	hooanon05@...oo.co.jp
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Q. Switch open_exec() and sys_uselib() to do_open_filp() 


Al Viro:
> On Mon, May 11, 2009 at 09:55:17AM +0900, hooanon05@...oo.co.jp wrote:
> > 
> > By the commit 6e8341a11eb21826b7192d0bb88cb5b44900a9af
> > "Switch open_exec() and sys_uselib() to do_open_filp()",
> > FMODE_EXEC flag is passed to struct file. I have no objection nor
> > question about that.
> > 
> > But it is set to file->f_flags instead of f_mode.
> > Is this intended behaviour?
> 
> It is previously existing behaviour.  Check what path_lookup_open() does
> and how had it used to be called.

My poor English may make me misunderstood.
Please let me make sure.
Do you mean FMODE_EXEC was passed to struct file before this commit?

Previous open_exec() used to call
	file = nameidata_to_filp(&nd, O_RDONLY|O_LARGEFILE)
and it calls
	filp = __dentry_open(nd->path.dentry, nd->path.mnt, flags, filp,
				     NULL);
__dentry_open()
{
	f->f_flags = flags;
	f->f_mode = ((flags+1) & O_ACCMODE) | FMODE_LSEEK |
				FMODE_PREAD | FMODE_PWRITE;
	;;;
}

So FMODE_EXEC was not set to f_flags/f_mode, O_RDONLY|O_LARGEFILE only.

After the commit, open_exec() calls
	file = do_filp_open(AT_FDCWD, name,
				O_LARGEFILE | O_RDONLY | FMODE_EXEC, 0,
				MAY_EXEC | MAY_OPEN);
and it calls
	filp = nameidata_to_filp(&nd, open_flag);

So f_flags becomes containing FMODE_EXEC, O_LARGEFILE | O_RDONLY | FMODE_EXEC.
This change of the behaviour is my question since a strict type fmode_t
was defined in 2.6.28 or 29 and FMODE_EXEC looks being set to f_mode.

If setting FMODE_xxx to f_flags is intended, it is OK.


J. R. Okajima
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ