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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
