linux-kernel - Re: [patch 01/15] security: pass path to inode

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, 03 Jun 2008 08:08:44 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	haradats@...il.com
CC:	johnpol@....mipt.ru, miklos@...redi.hu, hch@...radead.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, jmorris@...ei.org,
	sds@...ho.nsa.gov, eparis@...hat.com, casey@...aufler-ca.com,
	agruen@...e.de, jjohansen@...e.de,
	penguin-kernel@...ove.sakura.ne.jp, viro@...iv.linux.org.uk,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 01/15] security: pass path to inode_create

> Actually, another option has been suggested last month.
> http://lkml.org/lkml/2008/4/9/93

Yes, thanks for the link.

Here's the relevant quote from that mail from Stephen Smalley:

 "2) Submit patches to add new security hooks to the callers where the
  vfsmount is already available (some have suggested moving the
  existing security_inode hooks to the callers, but that would cause
  problems for SELinux as I've posted elsewhere, so adding new hooks
  is preferable, and then SELinux can just default to the dummy
  functions for those new hooks)."

True, this is an alternative, but from the VFS point of view it's
actually _worse_ than moving the hooks out, since we now have two sets
of security hooks littering the code for no good reason.

If Matthew Wilcox's idea can be made to work, that's obviously the
best, since it means that the VFS doesn't need to be touched at all.

Otherwise passing down vfsmounts is a superior solution to everything
else.  It has *absolutely* *no* downsides.  None, zero, zilch.

Well apart from the matter of VFS maintainers opinions.  But damit,
this is an open source project, where decisions are made on technical
merit, and not on personal whims.

If the VFS maintainers don't like it, they better state their reasons
in clear and concise terms.  An no, things like "someone might perhaps
maybe in the future need to call the vfs without a vfsmount" is
absolutely not a good reason.  When we have such a caller, we'll fix
the code.  It happens all the time.  Prepering for everything that
might happen is called overdesign and it's one of the worst and
commonest mistakes in software engineering.

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