linux-kernel - Re: [PATCH] vfs: automount should ignore LOOKUP

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:	Tue, 06 Sep 2011 12:03:00 +0800
From:	Ian Kent <raven@...maw.net>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	David Howells <dhowells@...hat.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Leonardo Chiquitto <leonardo.lists@...il.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	autofs@...ux.kernel.org
Subject: Re: [PATCH] vfs: automount should ignore LOOKUP_FOLLOW

On Tue, 2011-09-06 at 11:53 +0800, Ian Kent wrote:
> On Mon, 2011-09-05 at 19:02 +0200, Miklos Szeredi wrote:
> > David Howells <dhowells@...hat.com> writes:
> > 
> > > Miklos Szeredi <miklos@...redi.hu> wrote:
> > >
> > >> After 2.6.38, with the introduction of the ->d_automount()
> > >> infrastructure, stat(2) and others would start triggering automount
> > >> while lstat(2), etc. still would not.  This is a regression and a
> > >> userspace ABI change.
> > >
> > > It doesn't necessarily mean it's wrong.  The main class of program that needs
> > > to be prevented from automounting are things that do bulk stat'ing (e.g. ls) -
> > > and they should probably be doing lstat() anyway.
> > 
> > Yeah, some of those uses are probably minor bugs in userspace, but there are
> > probably many of them (Leonardo reported that for example Nautilus also
> > triggers all child automounts in a directory).  So I don't think it's OK to
> > just change the behavior here.
> 
> Yes, Leonard has been a big help with his recent efforts, thanks
> Leonard.
> 
> > 
> > If automounting on lstat(2) is the correct behavior (is it?  why?)  then at
> > least it should be enabled by a global switch or mount option, IMO.
> 
> Ideally we wouldn't need to take special precautions for these
> operations at all but we can't, especially for GUI environments that
> constantly scan file systems on mount/umount activity.
> 
> Historically for autofs, neither stat(2) or lstat(2) would trigger a
> mount. With the current implementation stat(2) now does but lstat(2)
> doesn't which is a step in the right direction IMHO. So, I recommend we
> continue to encourage user space to make the needed changes so we
> continue to move in the right direction, and yes, I acknowledge it is a
> pain but it'll never get done otherwise.
> 
> And, yes, other subsystems that need to automount also have the same
> problems as autofs now so we do need to take precautions, but that was
> already the case before the current implementation.
> 
> Hopefully, in time, user space will adopt the use of fcntl(2) and
> AT_NO_AUTOMOUNT and we will be able to fix this once and for all, as
> this was David's intent in introducing it. Not quite sure how we will go
> about promoting that adoption or how much pain that will mean for user
> space though.

Actually, maybe that's not entirely sensible either, now that I think
about it. Isn't it so that if we have one process that shouldn't trigger
mounts and sets the flag, other processes that possibly should won't
either ... mmm ... I'll need to check that.

Ian

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