On Sat, Apr 14, 2018 at 12:41:31AM +0200, Djalal Harouni wrote:
> On Wed, Apr 4, 2018 at 4:45 PM, Eric W. Biederman
> wrote:
> [...]
> >
> > The only option I have seen proposed that might qualify as something
> > general purpose and simple is a new filesystem that is just the process
> > directo
On Wed, Apr 4, 2018 at 4:45 PM, Eric W. Biederman wrote:
[...]
>
> The only option I have seen proposed that might qualify as something
> general purpose and simple is a new filesystem that is just the process
> directories of proc. As there would in essence be no files that would
> need restrict
On Wed, Apr 04, 2018 at 09:45:43AM -0500, Eric W. Biederman wrote:
> Alban Crequy writes:
>
> > Since Linux v4.2 with commit 1b852bceb0d1 ("mnt: Refactor the logic for
> > mounting sysfs and proc in a user namespace"), new mounts of proc or
> > sysfs in non init userns are only allowed when there
Alexey Dobriyan writes:
>> The only option I have seen proposed that might qualify as something
>> general purpose and simple is a new filesystem that is just the process
>> directories of proc.
>
> While "mount -t pid" and "mount -t sysctl" are decades overdue, I don't
> think they cover everyth
"Serge E. Hallyn" writes:
> Quoting Eric W. Biederman (ebied...@xmission.com):
>> It looks like a cruft free cousin of proc that is just processes would
>> be applicable to your usecase.
>
> Just to check - is that something you're working on?
Only to the point of reviewing code, and I don't hav
Quoting Eric W. Biederman (ebied...@xmission.com):
> It looks like a cruft free cousin of proc that is just processes would
> be applicable to your usecase.
Just to check - is that something you're working on?
-serge
> The only option I have seen proposed that might qualify as something
> general purpose and simple is a new filesystem that is just the process
> directories of proc.
While "mount -t pid" and "mount -t sysctl" are decades overdue, I don't
think they cover everything.
IIRC some gcc versions read
> Instead, it introduces new options in proc to disable some proc entries (TBD).
No, no, no, no.
Blacklists are bad, mmkay.
The reason is that quite dangerous new /proc entries get added
(think /proc/kpageflags) and suddenly they are enabled inside container.
> The granularity does not need to
On 2018-04-04, Eric W. Biederman wrote:
> > The following commands show my problem:
> >
> > $ sudo docker run -ti --rm --cap-add=SYS_ADMIN busybox sh -c 'unshare -U -r
> > -p -m -f mount -t proc proc /home && echo ok'
> > mount: permission denied (are you root?)
> >
> > $ sudo docker run -ti --rm
Alban Crequy writes:
> Since Linux v4.2 with commit 1b852bceb0d1 ("mnt: Refactor the logic for
> mounting sysfs and proc in a user namespace"), new mounts of proc or
> sysfs in non init userns are only allowed when there is at least one
> fully-visible proc or sysfs mount.
>
> This is to enforce
Since Linux v4.2 with commit 1b852bceb0d1 ("mnt: Refactor the logic for
mounting sysfs and proc in a user namespace"), new mounts of proc or
sysfs in non init userns are only allowed when there is at least one
fully-visible proc or sysfs mount.
This is to enforce that proc/sysfs files masked by a
11 matches
Mail list logo
