Re: [tip:x86/mm] x86/mmap, ASLR: Do not treat unlimited-stack tasks as legacy mmap
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [tip:x86/mm] x86/mmap, ASLR: Do not treat unlimited-stack tasks as legacy mmap
- From: Jiri Kosina <jikos@xxxxxxxxxx>
- Date: Wed, 28 Jun 2017 11:40:06 +0200 (CEST)
- Cc: tip-bot for Michal Hocko <tipbot@xxxxxxxxx>, linux-tip-commits@xxxxxxxxxxxxxxx, torvalds@xxxxxxxxxxxxxxxxxxxx, mingo@xxxxxxxxxx, hpa@xxxxxxxxx, mhocko@xxxxxxxx, tglx@xxxxxxxxxxxxx, davej@xxxxxxxxxxxxxxxxx, peterz@xxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
- In-reply-to: <20170627142215.GA5645@redhat.com>
- References: <20170614082218.12450-1-mhocko@kernel.org> <tip-86b110d2ae6365ce91cabd37588bc8611770421a@git.kernel.org> <20170623145441.GB9388@redhat.com> <alpine.LSU.2.20.1706270958520.30709@cbobk.fhfr.pm> <20170627142215.GA5645@redhat.com>
- User-agent: Alpine 2.20 (LSU 67 2015-01-07)
On Tue, 27 Jun 2017, Oleg Nesterov wrote:
> Perhaps it makes sense to reset RLIMITs on suid exec (say, if
> bprm->per_clear is not zero) ? Yes, it is not clear how should we define
> SANE_RLIMITS_FOR_SUID, and this should probably depend on sysctl, etc.
Hmm, this should be an userspace-defined policy. On a 'standard'
(PAM-based) system, I think a sane expectation would be to get the same
limits as the ones enforced by pam_limits configuration, but syncing those
with kernel feels awkward.
Thanks,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]