euidaccess() as syscall

euidaccess() as syscall

[Oleg Verych]

Hallo.

Why there's no euidaccess() syscall (most obvious use is in `test` or
`[` utility)?

Instead euiaccess() in glibc and access() in kernel are doing unnecessary uid
shuffling.

Thanks.
-- 
sed 'sed && sh + olecom = love' << ''
-o--=O`C
 #oo'L O
<___=E M

Re: euidaccess() as syscall

[Matthew Wilcox]

On Fri, May 02, 2008 at 05:59:36PM +0100, Oleg Verych wrote:
> Hallo.
> 
> Why there's no euidaccess() syscall (most obvious use is in `test` or
> `[` utility)?
> 
> Instead euiaccess() in glibc and access() in kernel are doing unnecessary uid
> shuffling.

Are there any programs which care?  Do you have a benchmark that might
show an improvement if we added an euidaccess() syscall?

My impression was that most programs ignore the access() family of
syscalls and just try to do the open and cope with the failure.  They
have to anyway, since the file could have changed permission between the
call to access() and the call to open().

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: euidaccess() as syscall

[Oleg Verych]

Matthew Wilcox @ Fri, May 2, 2008 at 6:06 PM:
> On Fri, May 02, 2008 at 05:59:36PM +0100, Oleg Verych wrote:
>  > Hallo.
>  >
>  > Why there's no euidaccess() syscall (most obvious use is in `test` or
>  > `[` utility)?
>  >
>  > Instead euiaccess() in glibc and access() in kernel are doing unnecessary uid
>  > shuffling.
>
>  Are there any programs which care?  Do you have a benchmark that might
>  show an improvement if we added an euidaccess() syscall?
>
>  My impression was that most programs ignore the access() family of
>  syscalls and just try to do the open and cope with the failure.  They
>  have to anyway, since the file could have changed permission between the
>  call to access() and the call to open().

open() will change timestamp. `bash` and `dash` have very broken workarounds of
access() in `test` due to euid requirements. I.e. read-only fs for
root or various
selinux-like restrictions are not shown unless open() is used.

So, it's better just to use stat64(), right?
____

Re: euidaccess() as syscall

[Jamie Lokier]

Oleg Verych wrote:
> open() will change timestamp. `bash` and `dash` have very broken workarounds of
> access() in `test` due to euid requirements. I.e. read-only fs for
> root or various
> selinux-like restrictions are not shown unless open() is used.
> 
> So, it's better just to use stat64(), right?

The whole point of access() originally seems to be so you can check
the real-user permissions, as there is no reliable way to do that
otherwise.

euidaccess() was added much later.  As noted, you can use open()
instead.  This is one reason why open() shouldn't change the
timestamps: only reading and writing should do that.

Windows has an additional open flag OF_EXIST, which lets you call the
Windows equivalent of open() and just check if you can, with the
specified open flags, without returning a handle.  Perhaps Linux could
copy that idea with an O_ACCESS flag to open()?

-- Jamie

Re: euidaccess() as syscall

[Oleg Verych]

Jamie Lokier @ Fri, 2 May 2008 18:33:43 +0100:
> Oleg Verych wrote:
>  > open() will change timestamp. `bash` and `dash` have very broken workarounds of
>  > access() in `test` due to euid requirements. I.e. read-only fs for
>  > root or various
>  > selinux-like restrictions are not shown unless open() is used.
>  >
>  > So, it's better just to use stat64(), right?
>
>  The whole point of access() originally seems to be so you can check
>  the real-user permissions, as there is no reliable way to do that
>  otherwise.

Reliable in kernel or in userspace applications? The only problem i
see in sys_faccessat() is "There is a race here against sys_capset",
and it relates to that access() have to change `cap_effective'.

Scripts of ordinary single-users or correct applications may have no
problems with this. Yet former have problems with simple checks.

>  euidaccess() was added much later.  As noted, you can use open()
>  instead.  This is one reason why open() shouldn't change the
>  timestamps: only reading and writing should do that.

More correctly: open() with some flags *will* change timestamp, thus
generally it does.

Matthew Wilcox @ Fri, 2 May 2008 11:35:13 -0600:
[]
> But if the shell is interpreting code, I would bet that a couple of euid
> changes aren't going to make even a blip in the overall performance
> profile.  If I'm wrong, please show me!

glibc is only libc (from dietlibc, uclibc, klibc) have at least something called
euiaccess() or eaccess().

That code checks for uids; in case if non set-uid, it calls access() which does
uid/caps shuffling. This wrapping and shuffling is not needed in euidaccess()
syscall. No?

And finally in set-uid case it calls stat64() with

> I don't think stat64 will tell you about selinux or rofs restrictions.

side-effect.

Thus, i conclude, that there's no way of doing check simply for ordinary
situations. It may have side-effects for (rare case for shell scripts) of
set-uid application.

Unneeded code path is there, but i'm not sure run overhead is
measurable. Inflexibility and bug reports are, however.
-- 
sed 'sed && sh + olecom = love' << ''
-o--=O`C
 #oo'L O
<___=E M

code example (Re: euidaccess() as syscall)

[Oleg Verych]

> Unneeded code path is there, but i'm not sure run overhead is
> measurable. Inflexibility and bug reports are, however.

Based on stripped, thus raceless-in-kernel
linux-2.6/fs/open.c:sys_faccessat()

Example expects non-error part to be likely, doesn't use "goto" in basic
stuff, isn't going to be used with unlikely_buggy(optimizing) GCC.

Comments?

# lang:C
asmlinkage long sys_feuidaccessat(int dfd, const char __user *filename, int mode)
{
	struct nameidata nd;
	int res;

	/* where's F_OK, X_OK, W_OK, R_OK? */
	if (!(mode & ~S_IRWXO)) {
		/* here */
		res = __user_walk_fd(dfd, filename, LOOKUP_FOLLOW|LOOKUP_ACCESS, &nd);
		if (!res) {
			res = vfs_permission(&nd, mode);
			/* SuS v2 requires we report a read only fs too */
			if (res || special_file(nd.dentry->d_inode->i_mode)
			    || !(mode & S_IWOTH))
			{} else	if (IS_RDONLY(nd.dentry->d_inode))
				res = -EROFS;
			path_release(&nd);
		}
		return res;
	}
	return -EINVAL;
}
#
-- 
sed 'sed && sh + olecom = love' << ''
-o--=O`C
 #oo'L O
<___=E M

Re: euidaccess() as syscall

[Matthew Wilcox]

On Fri, May 02, 2008 at 06:13:00PM +0100, Oleg Verych wrote:
> open() will change timestamp. `bash` and `dash` have very broken
> workarounds of access() in `test` due to euid requirements. I.e.
> read-only fs for root or various
> selinux-like restrictions are not shown unless open() is used.
> 
> So, it's better just to use stat64(), right?

I don't think stat64 will tell you about selinux or rofs restrictions.

But if the shell is interpreting code, I would bet that a couple of euid
changes aren't going to make even a blip in the overall performance
profile.  If I'm wrong, please show me!

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."