Re: euidaccess() as syscall

["Oleg Verych" <olecom@gmail.com>]

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