On Tue, Dec 5, 2017 at 4:01 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Tue, Dec 5, 2017 at 3:37 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >> Overlayfs is following redirects even when redirects are disabled. If this >> is unintentional (probably the majority of cases) then this can be a >> problem. E.g. upper layer comes from untrusted USB drive, and attacker >> crafts a redirect to enable read access to otherwise unreadable >> directories. >> >> If "redirect=off", then turn off following as well as creation of >> redirects. If "redirect=follow", then turn on following, but turn off >> creation of redirects (which is what "redirect=off" does now). >> >> This is a backward incompatible change, so make it dependent on a config >> option. >> >> Reported-by: David Howells <dhowells@xxxxxxxxxx> >> Signed-off-by: Miklos Szeredi <mszeredi@xxxxxxxxxx> >> --- > [...] >> static bool ovl_index_def = IS_ENABLED(CONFIG_OVERLAY_FS_INDEX); >> module_param_named(index, ovl_index_def, bool, 0644); >> MODULE_PARM_DESC(ovl_index_def, >> @@ -315,7 +318,8 @@ static int ovl_show_options(struct seq_f >> seq_puts(m, ",default_permissions"); >> if (ofs->config.redirect_dir != ovl_redirect_dir_def) >> seq_printf(m, ",redirect_dir=%s", >> - ofs->config.redirect_dir ? "on" : "off"); >> + ofs->config.redirect_dir ? "on" : >> + (ofs->config.redirect_follow ? "follow" : "off")); > > > ovl_show_options() not reflecting mount options in several cases, for example: > ofs->config.redirect_dir == ovl_redirect_dir_def && > !ovl_redirect_dir_def && !ovl_redirect_follow_def && > ofs->config.redirect_follow > doesn't show "redirect_dir=follow" after user mounted with "-o > redirect_dir=follow" > > Another anomaly is with (ovl_redirect_dir_def && ovl_redirect_follow_def) > when user mounts with "-o redirect_dir=off", but /proc/mounts will show > "redirect_dir=follow". > > I guess that last one may be justified, but maybe requires a pr_info() on mount > to notify user that redirect_dir follow is always enabled even on > redirect_dir=off, > but the first one is just a bug. Indeed, well spotted. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
