FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 01-19-2012, 03:30 PM
Henrique de Moraes Holschuh
 
Default Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

On Thu, 19 Jan 2012, Paul Eggert wrote:
> On 01/19/12 07:29, Henrique de Moraes Holschuh wrote:
> > Note: there is no reason why the kernel could not return the mount
> > information with shadowed paths removed in a separate procfs node, as
> > that would cause no security/troubleshooting problems.
>
> That's what I was thinking of, and it'd be a much better fix,
> as it would fix things for all applications.
>
> The current approach expects all app developers to modify
> their applications in order to deal with a feature that app
> developers typically don't know about and don't understand;
> this isn't a good way to introduce a new feature.

On the app side, I will tell you what you're likely to get back from the
crowd on LKML: write a proper BSD/MIT/LGPL library so that people don't
have to reinvent the wheel, and fix it in userspace. It gets worse: such
library interface already exists, in the form of getmntent, setmntent,
addmntent, endmntent, hasmntopt, getmntent_r. So they will tell you to fix
it in glibc.

AFAIK, the kernel is not in any better position to remove shadowed paths
than userspace, both are perfectly capable of doing it. Now, removing
paths that are outside of the current process scope (due to namespaces or
chroot or whatever), THAT is something only the kernel can do correctly...

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120119163006.GC9187@khazad-dum.debian.net">http://lists.debian.org/20120119163006.GC9187@khazad-dum.debian.net
 
Old 01-20-2012, 06:50 AM
Goswin von Brederlow
 
Default Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

Henrique de Moraes Holschuh <hmh@debian.org> writes:

> On Thu, 19 Jan 2012, Paul Eggert wrote:
>> On 01/19/12 07:29, Henrique de Moraes Holschuh wrote:
>> > Note: there is no reason why the kernel could not return the mount
>> > information with shadowed paths removed in a separate procfs node, as
>> > that would cause no security/troubleshooting problems.
>>
>> That's what I was thinking of, and it'd be a much better fix,
>> as it would fix things for all applications.
>>
>> The current approach expects all app developers to modify
>> their applications in order to deal with a feature that app
>> developers typically don't know about and don't understand;
>> this isn't a good way to introduce a new feature.
>
> On the app side, I will tell you what you're likely to get back from the
> crowd on LKML: write a proper BSD/MIT/LGPL library so that people don't
> have to reinvent the wheel, and fix it in userspace. It gets worse: such
> library interface already exists, in the form of getmntent, setmntent,
> addmntent, endmntent, hasmntopt, getmntent_r. So they will tell you to fix
> it in glibc.

How do you decide which of two conflicting entries is real? Since mount
--move does not change the order of entries you can not just pick the
last one.

For example which entry is the right one with an output like this:

tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=357828k,mode=755 0 0
tmpfs /run tmpfs rw,suid,exec,relatime,size=357828k,mode=755 0 0

I don't think this can be fixed in userspace alone. At a minimum the
kernel has to keep entries in order of visibility, i.e. the later
entries always shadow earlier entries. Which means that on mount --move
the kernel has to move the entry in /proc/mounts up or down as needed.

MfG
Goswin

PS: I think you can also mount something below an already shadowed entry
(if you have a shell with cwd in the shadowed one) and it would show up
in the wrong spot in /proc/mounts.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87zkdilsm8.fsf@frosties.localnet">http://lists.debian.org/87zkdilsm8.fsf@frosties.localnet
 
Old 01-20-2012, 04:28 PM
Henrique de Moraes Holschuh
 
Default Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

On Fri, 20 Jan 2012, Goswin von Brederlow wrote:
> Henrique de Moraes Holschuh <hmh@debian.org> writes:
> > On Thu, 19 Jan 2012, Paul Eggert wrote:
> >> On 01/19/12 07:29, Henrique de Moraes Holschuh wrote:
> >> > Note: there is no reason why the kernel could not return the mount
> >> > information with shadowed paths removed in a separate procfs node, as
> >> > that would cause no security/troubleshooting problems.
> >>
> >> That's what I was thinking of, and it'd be a much better fix,
> >> as it would fix things for all applications.
> >>
> >> The current approach expects all app developers to modify
> >> their applications in order to deal with a feature that app
> >> developers typically don't know about and don't understand;
> >> this isn't a good way to introduce a new feature.
> >
> > On the app side, I will tell you what you're likely to get back from the
> > crowd on LKML: write a proper BSD/MIT/LGPL library so that people don't
> > have to reinvent the wheel, and fix it in userspace. It gets worse: such
> > library interface already exists, in the form of getmntent, setmntent,
> > addmntent, endmntent, hasmntopt, getmntent_r. So they will tell you to fix
> > it in glibc.
>
> How do you decide which of two conflicting entries is real? Since mount
> --move does not change the order of entries you can not just pick the
> last one.
>
> For example which entry is the right one with an output like this:
>
> tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=357828k,mode=755 0 0
> tmpfs /run tmpfs rw,suid,exec,relatime,size=357828k,mode=755 0 0
>
> I don't think this can be fixed in userspace alone. At a minimum the
> kernel has to keep entries in order of visibility, i.e. the later
> entries always shadow earlier entries. Which means that on mount --move
> the kernel has to move the entry in /proc/mounts up or down as needed.

Yes, it would have to order in that way.

> PS: I think you can also mount something below an already shadowed entry
> (if you have a shell with cwd in the shadowed one) and it would show up
> in the wrong spot in /proc/mounts.

I believe that's correct, and should be fixed.

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120120172818.GA18413@khazad-dum.debian.net">http://lists.debian.org/20120120172818.GA18413@khazad-dum.debian.net
 

Thread Tools




All times are GMT. The time now is 04:56 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org