linux-kernel - Re: [patch] honour MNT

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 07 Oct 2006 23:14:19 +0400
From:	Stas Sergeev <stsp@...et.ru>
To:	Ulrich Drepper <drepper@...hat.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jakub Jelinek <jakub@...hat.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Linux kernel <linux-kernel@...r.kernel.org>,
	Hugh Dickins <hugh@...itas.com>
Subject: Re: [patch] honour MNT_NOEXEC for access()

Hello.

Ulrich Drepper wrote:
>> Now, as the access(X_OK) is fixed, would it be
>> feasible for ld.so to start using it?
> Just must be kidding.  No access control can be reliably implemented at
> userlevel.  There is no point starting something as stupid as this.
But in this case how can you ever solve the
problem of ld.so executing the binaries for which
the user does not have an exec permission?
Yes, the userspace apps usually should not enforce
the kernel's access control, but ld.so seems to be
the special case - it is a kernel helper after all,
so it have to be carefull and check what it does.

-
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/