linux-kernel - Re: [PATCH] autofs - fix fix symlinks arent checked for expiry

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 27 Dec 2013 09:09:52 +0800
From:	Ian Kent <raven@...maw.net>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	autofs mailing list <autofs@...r.kernel.org>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] autofs - fix fix symlinks arent checked for expiry

On Thu, 2013-12-26 at 13:42 -0800, Andrew Morton wrote:
> On Tue, 24 Dec 2013 17:44:59 +0800 Ian Kent <raven@...maw.net> wrote:
> 
> > When following a symlink the last_used counter is unconditionally
> > updated causing the expire checks from user space to prevent
> > expiry. Opps!
> 
> A bit unclear.  You're saying that userspace's act of checking expiry
> status will itself disrupt the expiry process?

If the user space expire code uses stat(2) instead of lstat(2), yes.
It's quite possible this will be the case since it made no difference
when not using symlinks in the autofs directory tree.

> 
> Also, it's rather unclear what the userspace impact is here, and how
> severe it is.  Please always carefully describe the user-visible impact
> so that others can decide which kernel version(s) need the patch.

The impact of this is that symlinks within an an autofs directory tree
don't cause a callback to the daemon so they can be expired (removed in
this case).

autofs4_oz_mode() is the mechanism that's used to identify the user
space process that's managing the automount tree. It's used in a number
of places to prevent the process managing the tree from doing things
like triggering mounts itself or updating the last_used counter.

It's a bit of a puzzle why it worked when I originally tested it.  But
later when I looked at it to work out why some symlinks weren't expiring
it was obvious.

Do you want me to re-submit this with an updated description?

> 
> > --- a/fs/autofs4/symlink.c
> > +++ b/fs/autofs4/symlink.c
> > @@ -14,8 +14,9 @@
> >  
> >  static void *autofs4_follow_link(struct dentry *dentry, struct nameidata *nd)
> >  {
> > +	struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb);
> >  	struct autofs_info *ino = autofs4_dentry_ino(dentry);
> > -	if (ino)
> > +	if (ino && !autofs4_oz_mode(sbi))
> >  		ino->last_used = jiffies;
> >  	nd_set_link(nd, dentry->d_inode->i_private);
> >  	return NULL;
> 
> What kernel is this against?  3.13-rc5 is quite different:

That's a good question.
Which tree should I be basing patches on?

As it turns out it is against 3.13-rc5 which was the version the linus
tree was at (when I pulled it) prior to mailing the patch.

> 
> static void *autofs4_follow_link(struct dentry *dentry, struct nameidata *nd)
> {
> 	nd_set_link(nd, dentry->d_inode->i_private);
> 	return NULL;
> }
> 

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/