roughly the original
performance.
Signed-off-by: Andreas Gruenbacher
---
security/selinux/hooks.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 40e071a..f8110cf 100644
--- a/security/selinux/hooks.c
+++ b
On Mon, Nov 2, 2015 at 8:27 PM, Paul Moore wrote:
> On Sunday, November 01, 2015 06:24:32 PM Andreas Gruenbacher wrote:
>> When fetching an inode's security label, check if it is still valid, and
>> try reloading it if it is not. Reloading will fail when we are in RCU
>
Paul,
On Sun, Nov 1, 2015 at 1:52 PM, Paul Moore wrote:
> If you want, you can just post a
> "8/7" patch with the extra calls added and I'll apply that on top of
> the v4 patchset.
I've also added the additional Acked-by headers, it's easiest to just
repost (I just did).
Thanks,
Andreas
--
To u
(sock) inodes.
This patch queue is also available here:
git://git.kernel.org/pub/scm/linux/kernel/git/agruen/linux.git selinux-wip
Thanks,
Andreas
Andreas Gruenbacher (7):
selinux: Remove unused variable in selinux_inode_init_security
security: Make inode argument of inode_getsecurity non
Make the inode argument of the inode_getsecurity hook non-const so that
we can use it to revalidate invalid security labels.
Signed-off-by: Andreas Gruenbacher
Acked-by: Stephen Smalley
---
include/linux/lsm_hooks.h | 2 +-
include/linux/security.h | 4 ++--
security/security.c| 2
Add a hook to invalidate an inode's security label when the cached
information becomes invalid.
Add the new hook in selinux: set a flag when a security label becomes
invalid.
Signed-off-by: Andreas Gruenbacher
Reviewed-by: James Morris
Acked-by: Stephen Smalley
---
include/linux/lsm_ho
Signed-off-by: Andreas Gruenbacher
Acked-by: Stephen Smalley
---
security/selinux/hooks.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index e4369d8..fc8f626 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
reacquiring the glock.
Signed-off-by: Andreas Gruenbacher
Acked-by: Bob Peterson
Acked-by: Steven Whitehouse
Cc: cluster-de...@redhat.com
---
fs/gfs2/glops.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
index 1f6c9c3..0833076 100644
--- a/fs/gfs2/glops.c
Add functions dentry_security and inode_security for accessing
inode->i_security. These functions initially don't do much, but they
will later be used to revalidate the security labels when necessary.
Signed-off-by: Andreas Gruenbacher
Acked-by: Stephen Smalley
---
security/selinux
a dentry
parameter.) When reloading fails, continue using the old, invalid
label.
Signed-off-by: Andreas Gruenbacher
Acked-by: Stephen Smalley
---
security/selinux/hooks.c | 76 +++-
1 file changed, 68 insertions(+), 8 deletions(-)
diff --git a/security
Make the inode argument of the inode_getsecid hook non-const so that we
can use it to revalidate invalid security labels.
Signed-off-by: Andreas Gruenbacher
Acked-by: Stephen Smalley
---
include/linux/audit.h | 8
include/linux/lsm_hooks.h | 2 +-
include/linux/security.h | 4
David,
On Thu, Oct 29, 2015 at 1:47 AM, Andreas Gruenbacher
wrote:
> When fetching an inode's security label, check if it is still valid, and
> try reloading it if it is not. Reloading will fail when we are in RCU
> context which doesn't allow sleeping, or when we can't
On Thu, Oct 29, 2015 at 4:21 PM, Stephen Smalley wrote:
> On 10/28/2015 08:47 PM, Andreas Gruenbacher wrote:
>>
>> When fetching an inode's security label, check if it is still valid, and
>> try reloading it if it is not. Reloading will fail when we are in RCU
>
patch queue, the SELinux test suite passes:
https://github.com/SELinuxProject/selinux-testsuite
Could you please review?
Thanks,
Andreas
Andreas Gruenbacher (7):
selinux: Remove unused variable in selinux_inode_init_security
security: Make inode argument of inode_getsecurity non-const
Make the inode argument of the inode_getsecurity hook non-const so that
we can use it to revalidate invalid security labels.
Signed-off-by: Andreas Gruenbacher
---
include/linux/lsm_hooks.h | 2 +-
include/linux/security.h | 4 ++--
security/security.c| 2 +-
security/selinux/hooks.c
reacquiring the glock.
Signed-off-by: Andreas Gruenbacher
Cc: Steven Whitehouse
Cc: Bob Peterson
Cc: cluster-de...@redhat.com
---
fs/gfs2/glops.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
index 1f6c9c3..0833076 100644
--- a/fs/gfs2/glops.c
+++ b/fs/gfs2
Add a hook to invalidate an inode's security label when the cached
information becomes invalid.
Add the new hook in selinux: set a flag when a security label becomes
invalid.
Signed-off-by: Andreas Gruenbacher
Reviewed-by: James Morris
---
include/linux/lsm_hooks.h
Add functions dentry_security and inode_security for accessing
inode->i_security. These functions initially don't do much, but they
will later be used to revalidate the security labels when necessary.
Signed-off-by: Andreas Gruenbacher
---
security/selinux/hook
Make the inode argument of the inode_getsecid hook non-const so that we
can use it to revalidate invalid security labels.
Signed-off-by: Andreas Gruenbacher
---
include/linux/audit.h | 8
include/linux/lsm_hooks.h | 2 +-
include/linux/security.h | 4 ++--
kernel/audit.c
Signed-off-by: Andreas Gruenbacher
Acked-by: Stephen Smalley
---
security/selinux/hooks.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index e4369d8..fc8f626 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
a dentry
parameter.) When reloading fails, continue using the old, invalid
label.
Signed-off-by: Andreas Gruenbacher
---
security/selinux/hooks.c | 70
1 file changed, 65 insertions(+), 5 deletions(-)
diff --git a/security/selinux/hooks.c b/securi
On Wed, Oct 28, 2015 at 7:56 PM, Stephen Smalley wrote:
> On 10/28/2015 01:31 PM, Stephen Smalley wrote:
>>
>> On 10/28/2015 07:48 AM, Andreas Gruenbacher wrote:
>>>
>>> On Tue, Oct 27, 2015 at 5:40 PM, Stephen Smalley
>>> wrote:
>>>>
On Wed, Oct 28, 2015 at 10:12 PM, Paul Moore wrote:
> On Mon, Oct 26, 2015 at 5:15 PM, Andreas Gruenbacher
> wrote:
>> Here is another version of the patch queue to make gfs2 and similar file
>> systems work with SELinux. As suggested by Stephen Smalley [*], the relevan
On Tue, Oct 27, 2015 at 6:20 PM, Stephen Smalley wrote:
> On 10/26/2015 05:15 PM, Andreas Gruenbacher wrote:
>> @@ -2217,7 +2231,7 @@ static int selinux_bprm_set_creds(struct
>> linux_binprm *bprm)
>>
>> old_tsec = current_security();
>>
On Tue, Oct 27, 2015 at 5:40 PM, Stephen Smalley wrote:
> On 10/26/2015 05:15 PM, Andreas Gruenbacher wrote:
>>
>> Use path_has_perm directly instead.
>
>
> This reverts:
>
> commit 13f8e9810bff12d01807b6f92329111f45218235
> Author: David Howells
> Da
a dentry parameter.)
Signed-off-by: Andreas Gruenbacher
---
security/selinux/hooks.c | 47 +++
1 file changed, 39 insertions(+), 8 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index f93dafd..61aead9 100644
--- a/securi
In dentry_has_perm, path_has_perm, and file_has_perm, push the dentry down
to before avc_has_perm so that dentry_security can be used instead of
inode_security. Since inode_has_perm now takes a dentry, rename it to
__dentry_has_perm.
Signed-off-by: Andreas Gruenbacher
---
security/selinux
reacquiring the glock.
Signed-off-by: Andreas Gruenbacher
Cc: Steven Whitehouse
Cc: Bob Peterson
Cc: cluster-de...@redhat.com
---
fs/gfs2/glops.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/gfs2/glops.c b/fs/gfs2/glops.c
index 1f6c9c3..0833076 100644
--- a/fs/gfs2/glops.c
+++ b/fs/gfs2
Signed-off-by: Andreas Gruenbacher
---
security/selinux/hooks.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index e4369d8..fc8f626 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -2756,13 +2756,11 @@ static int
Use path_has_perm directly instead.
Signed-off-by: Andreas Gruenbacher
---
security/selinux/hooks.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 65e8689..d6b4dc9 100644
--- a/security/selinux
Add functions dentry_security and inode_security for accessing
inode->i_security. These functions initially don't do much, but they
will later be used to revalidate the security labels when necessary.
Signed-off-by: Andreas Gruenbacher
---
security/selinux/hooks
If an inode does not have any dentries attached, we cannot reload its
security label because we cannot use the getxattr inode operation. In that
case, continue using the old, invalid label until a dentry becomes
available.
Signed-off-by: Andreas Gruenbacher
---
include/linux/lsm_hooks.h
l&m=144416710207686&w=2
The patches are looking good from my point of view; is there anything else that
needs addressing?
Does SELinux have test suites that these patches could be tested agains?
Thanks,
Andreas
Andreas Gruenbacher (7):
selinux: Remove unused variable in selinux_inode_init_securit
On Mon, Oct 5, 2015 at 8:24 PM, Casey Schaufler wrote:
> On 10/4/2015 12:19 PM, Andreas Gruenbacher wrote:
>> Add a hook to invalidate an inode's security label when the cached
>> information becomes invalid.
>
> Where is this used?
See the next patch in this patch qu
On Saturday 27 October 2007 22:47, Christoph Hellwig wrote:
> On Fri, Oct 26, 2007 at 07:37:21AM -0700, Arjan van de Ven wrote:
> > before going into the LSM / security side of things, I'd like to get
> > the VFS guys to look at your VFS interaction code.
>
> It's been NACKed a few times, and just
On Friday 26 October 2007 22:58:11 Miklos Szeredi wrote:
> For special files, f_op->fsetattr will be NULL, since
> init_special_inode() will set up i_fop that way.
>
> So the filesystem's fsetattr() will only be called for regular files
> and/or directories, depending on how it sets up i_fop.
>
> W
On Friday 26 October 2007 23:13, Arjan van de Ven wrote:
> My main concern for now is a description of what it tries to protect
> against/in what cases you would expect to use it.
Okay, I see what you mean. Thanks.
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module"
On Friday 26 October 2007 16:37, Arjan van de Ven wrote:
> In addition, I'd like to ask you to put a file in Documentation/
> somewhere that describes what AppArmor is intended security protection
> is (it's different from SELinux for sure for example); by having such a
> document for each LSM user
On Friday 26 October 2007 13:30, Miklos Szeredi wrote:
> There's a slight problem (other than HCH not liking it) with this
> approach of passing the open file in iattr: for special files, the
> struct file pointer makes no sense to the filesystem, since it is always
> opened by the generic functio
at we'll have to do this much less frequently, and maybe we can sometimes
determine that the pwd hasn't changed and start checking from there, but
all of this wouldn't change the fundamental model or the slow path / worst
case.
--
Andreas Gruenbacher <[EMAIL PROTECTED
On Wednesday 15 August 2007 13:40, David Howells wrote:
>
> Hi Linus, Al,
>
> Would you object greatly to functions like vfs_mkdir() gaining a security
> parameter? What I'm thinking of is this:
>
> int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode,
> st
On Wednesday 15 August 2007 18:23, Casey Schaufler wrote:
> > Hi Linus, Al,
> >
> > Would you object greatly to functions like vfs_mkdir() gaining a security
> > parameter?
>
> Could you describe how this compares to the proposal that the
> AppArmor developers suggested recently? I expect that we
On Saturday 30 June 2007 11:29, Christoph Hellwig wrote:
> On Tue, Jun 26, 2007 at 04:07:57PM -0700, [EMAIL PROTECTED] wrote:
> > This is needed for computing pathnames in the AppArmor LSM.
>
> Please see the various per-mountpoint r/o thread that NACKed all the
> vfsmount additions and have the ra
On Tuesday 03 July 2007 15:49, Stephen Smalley wrote:
> So you don't actually need/use the struct file pointer; you just need a
> flag indicating whether or not access was by open file descriptor or by
> pathname?
Yes, indeed. Given that struct iattr already defines ATTR_FILE and ia_file, I
didn'
On Monday 02 July 2007 22:15, Christoph Hellwig wrote:
> AA on the other hand just fucks up VFS layering [...]
Oh come on, this claim clearly isn't justified. How on earth is passing
vfsmounts down the lsm hooks supposed to break vfs layering? We are not
proposing to pass additional information
On Saturday 30 June 2007 11:13, Christoph Hellwig wrote:
> We need something like this, but I don't quite like the way you've done
> it. First the name is wrong, it's not a nameidata anymore but a lookup
> intent, so it should be named that way, struct lookup_intent.
Sure, that name was pretty ra
On Thursday 28 June 2007 18:12, James Morris wrote:
> Are you trying to cater for the case where you're holding an open fd for a
> file which has been deleted, and thus has no pathname?
Yes, see the AA_CHECK_FD flag in security/apparmor/main.c:aa_perm_dentry(). We
want to distinguish between the
On Wednesday 27 June 2007 01:46, Trond Myklebust wrote:
> On Tue, 2007-06-26 at 16:15 -0700, [EMAIL PROTECTED] wrote:
> > To remove conditionally passing of vfsmounts to the LSM, a nameidata
> > struct can be instantiated in the nfsd and mqueue filesystems. This
> > however results in useless info
On Wednesday 27 June 2007 12:58, Kyle Moffett wrote:
> I seem to recall you could actually end up racing and building a path
> to the file in those directories as "a/d/0/3" or some other path at
> which it never even remotely existed. I'd love to be wrong,
Cheer up, you recall wrong.
> but I can'
On Monday 25 June 2007 06:33, James Morris wrote:
> Convert LSM into a static interface, as the ability to unload a security
> module is not required by in-tree users and potentially complicates the
> overall security architecture.
It's useful for some LSMs to be modular, and LSMs which are y/n
On Saturday 16 June 2007 02:20, Pavel Machek wrote:
> Ok, so mv gets slower for big trees... and open() gets faster for deep
> trees. Previously, open in current directory was one atomic read of
> directory entry, now it has to read directory, and its parent, and its
> parent parent, and its...
>
>
On Saturday 16 June 2007 01:49, Greg KH wrote:
> But for those types of models that do not map well to internal kernel
> structures, perhaps they should be modeled on top of a security system that
> does handle the internal kernel representation of things in the way the
> kernel works.
How exactly
On Monday 18 June 2007 15:33, Stephen Smalley wrote:
> On Fri, 2007-06-15 at 18:24 -0400, Karl MacMillan wrote:
> > There are two things:
> >
> > 1) relabeling (non-tranquility) is very problematic in general because
> > revocation is hard (and non-solved in Linux). So you would have to
> > address
On Monday 11 June 2007 16:33, Stephen Smalley wrote:
>From a userland perspective, audit and inotify allow you to specify
> watches on pathnames, and those watches trigger actions by the audit and
> inotify subsystems when those files are accessed. The kernel mechanism
> however is inode-based, no
On Monday 11 June 2007 16:33, Stephen Smalley wrote:
> On Mon, 2007-06-11 at 01:10 +0200, Andreas Gruenbacher wrote:
> > On Wednesday 06 June 2007 15:09, Stephen Smalley wrote:
> > > On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote:
> > > > On Monday 04
On Wednesday 06 June 2007 15:09, Stephen Smalley wrote:
> On Mon, 2007-06-04 at 16:30 +0200, Andreas Gruenbacher wrote:
> > On Monday 04 June 2007 15:12, Pavel Machek wrote:
> > > How will kernel work with very long paths? I'd suspect some problems,
> > > if path is
On Saturday 09 June 2007 10:10, Sean wrote:
> Clinging to the current AA implementation instead of honestly considering
> reasonable alternatives does not inspire confidence or teamwork.
What you imply is pretty insulting. I can assure you we looked into many
possible implementation choices, and
On Saturday 09 June 2007 02:17, Greg KH wrote:
> On Sat, Jun 09, 2007 at 12:03:57AM +0200, Andreas Gruenbacher wrote:
> > AppArmor is meant to be relatively easy to understand, manage, and
> > customize, and introducing a labels layer wouldn't help these goals.
>
>
On Saturday 09 June 2007 14:58, Pavel Machek wrote:
> > > How will kernel work with very long paths? I'd suspect some problems,
> > > if path is 1MB long and I attempt to print it in /proc
> > > somewhere.
> >
> > Pathnames are only used for informational purposes in the kernel, except
> > in App
On Wednesday 06 June 2007 15:26, Stephen Smalley wrote:
> On Mon, 2007-06-04 at 23:03 +0200, Andreas Gruenbacher wrote:
> > [...] SELinux turns pathnames into labels when it
> > initially labels all files (when a policy is rolled out), whereas
> > AppArmor computes the "
On Tuesday 15 May 2007 11:20, Pavel Machek wrote:
> Hi!
>
> > Pathname matching, transition table loading, profile loading and
> > manipulation.
>
> So we get small interpretter of state machines, and reason we need is
> is 'apparmor is misdesigned and works with paths when it should have
> worke
On Monday 04 June 2007 15:12, Pavel Machek wrote:
> How will kernel work with very long paths? I'd suspect some problems,
> if path is 1MB long and I attempt to print it in /proc
> somewhere.
Pathnames are only used for informational purposes in the kernel, except in
AppArmor of course. /proc onl
On Monday 04 June 2007 13:35, Pavel Machek wrote:
> On Mon 2007-06-04 13:25:30, Andreas Gruenbacher wrote:
> > On Monday 04 June 2007 12:55, Pavel Machek wrote:
> > > On Wed 2007-05-23 18:16:45, Andreas Gruenbacher wrote:
> > > > On Tuesday 15 May 2007 11:14, Pavel
On Monday 04 June 2007 12:55, Pavel Machek wrote:
> On Wed 2007-05-23 18:16:45, Andreas Gruenbacher wrote:
> > On Tuesday 15 May 2007 11:14, Pavel Machek wrote:
> > > Why is this configurable?
> >
> > The maximum length of a pathname is an arbitrary limit: we don&#x
On Tuesday 29 May 2007 22:47, Tetsuo Handa wrote:
> AppArmor can't determine which pathname (/tmp/public/file or
> /tmp/secret/file) was requested by touch command if bound mount is used in
> the following way
>
> # mkdir /tmp/public /tmp/secret
> # mount -t tmpfs none /tmp/public
> # mount --bin
On Tuesday 29 May 2007 12:46, Tetsuo Handa wrote:
> But, from the pathname-based access control's point of view,
> bind mount interferes severely with pathname-based access control
> because it is impossible to determine which pathname was requested.
Wrong. It is very well possible to determine th
On Saturday 26 May 2007 16:44, Tetsuo Handa wrote:
> Hello.
>
> Andreas Gruenbacher wrote:
> > > Therefore, TOMOYO Linux checks the combination of filename and argv[0]
> > > passed to execve().
> >
> > So you are indeed trying to control the value of argv
On Saturday 26 May 2007 15:34, Alan Cox wrote:
> > As such, AA can detect whether you did exec("gzip") or exec("gunzip")
> > and apply the policy relevant to the program. It could apply different
>
> That's not actually useful for programs which link the same binary to
> multiple names because if y
On Saturday 26 May 2007 14:09, Tetsuo Handa wrote:
> Hello.
>
> Andreas Gruenbacher wrote:
> > > exec { "/usr/bin/gunzip" } "gzip", "-9", "some/file/to.gz";
> >
> > The above Perl code executes /usr/bin/gunzip and sets argv[0]
On Friday 25 May 2007 21:06, Casey Schaufler wrote:
> --- Jeremy Maitin-Shepard <[EMAIL PROTECTED]> wrote:
> > ...
> > Well, my point was exactly that App Armor doesn't (as far as I know) do
> > anything to enforce the argv[0] convention,
>
> Sounds like an opportunity for improvement then.
Jeez,
On Saturday 26 May 2007 07:20, Kyle Moffett wrote:
> On May 24, 2007, at 14:58:41, Casey Schaufler wrote:
> > On Fedora zcat, gzip and gunzip are all links to the same file. I
> > can imagine (although it is a bit of a stretch) allowing a set of
> > users access to gunzip but not gzip (or the
On Friday 25 May 2007 19:43, Casey Schaufler wrote:
> [...] but the AppArmor code could certainly check for that in exec by
> enforcing the argv[0] convention. It would be perfectly reasonable for a
> system that is so dependent on pathnames to require that.
Hmm ... that's a strange idea. AppArmor
On Thursday 24 May 2007 20:58, Casey Schaufler wrote:
> On Fedora zcat, gzip and gunzip are all links to the same file.
> I can imagine (although it is a bit of a stretch) allowing a set
> of users access to gunzip but not gzip (or the other way around).
> There are probably more sophisticated prog
On Thursday 24 May 2007 20:40, Al Viro wrote:
> On Thu, May 24, 2007 at 08:10:00PM +0200, Andreas Gruenbacher wrote:
>
> > Read it like this: we don't have a good idea how to support multiple
> > namespaces so far. Currently, we interpret all pathnames relative to the
>
On Thursday 24 May 2007 15:19, James Morris wrote:
> On Thu, 24 May 2007, Andreas Gruenbacher wrote:
> > > Would you mind providing some concrete examples of how such a model
> > > would be useful?
> >
> > The model is explained, with examples, in the te
On Thursday 24 May 2007 03:28, James Morris wrote:
> On Wed, 23 May 2007, Andreas Gruenbacher wrote:
> > This is backwards from what AppArmor does. The policy defines which paths
> > may be accessed; all paths not explicitly listed are denied. If files are
> > mounted at mul
On Thursday 12 April 2007 12:12, Al Viro wrote:
> On Thu, Apr 12, 2007 at 02:08:10AM -0700, [EMAIL PROTECTED] wrote:
> > This is needed for computing pathnames in the AppArmor LSM.
>
> Which is an argument against said LSM in current form.
The fundamental model of AppArmor is to perform access che
On Tuesday 15 May 2007 11:14, Pavel Machek wrote:
> Why is this configurable?
The maximum length of a pathname is an arbitrary limit: we don't want to
allocate arbitrary amounts of of kernel memory for pathnames so we introduce
this limit and set it to a reasonable value. In the unlikely case t
On Monday 16 April 2007 18:21, Christoph Hellwig wrote:
> On Mon, Apr 16, 2007 at 06:11:30PM +0200, Andreas Gruenbacher wrote:
> > On Thursday 12 April 2007 12:06, Christoph Hellwig wrote:
> > > Once again very strong NACK. Every conditional passing of vfsmounts get
> >
On Sunday 22 April 2007 11:10, Christoph Hellwig wrote:
> So what about stopping the flaming here and implementing real statvfs/
> fstatvfs syscalls instead of these horrible hacks glibc has to do
> currently?
I could imagine two approaches to that: either add statvfs and fstatvfs
syscalls, or us
On Friday 20 April 2007 21:17, Ulrich Drepper wrote:
> On 4/20/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> > The code also seems to stop at the first matching mount point. You can
> > have the same device mounted on the same mount point multiple times but
> > w
On Saturday 21 April 2007 14:57, Tetsuo Handa wrote:
> So, you may want customized version of d_namespace_path()?
No. d_namespace_path() returns valid pathnames, just like d_path() does.
Whatever quoting needed can be added to the resulting pathname.
Andreas
-
To unsubscribe from this list: send
On Friday 20 April 2007 17:24, Ulrich Drepper wrote:
> On 4/20/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> > Yes, that one, sorry. The values it obtains that way are not reliable.
>
> Why should the mount point info together with the filesystem type not
> be reliab
On Friday 20 April 2007 17:15, Ulrich Drepper wrote:
> On 4/20/07, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> > Possibly for fstatfs(): fstatfs() has no way of looking up mount points
> > per path name in /proc/mounts, and so it resorts to mapping from the
> > nu
On Friday 20 April 2007 11:30, Alan Cox wrote:
> > As far as I can see, glibc internally looks at /proc/mounts (or else
> > mtab) to find out where tmpfs is mounted for opening files there, and to
> > look up filesystem information for statfs(), while accessing that path,
> > too. Fstatfs() also lo
On Tuesday 17 April 2007 19:21, Alan Cox wrote:
> Can you prove no existing application on the planet relies on the
> existing behaviour ? Actually more limited but sane as a test would be
> "Can you prove that the glibc behaviour visible to applications does not
> change"
As far as I can see, gli
always
consisent, and the file may never have had that name. (This is unlikely, but
still possible.)
Fix this by grabbing the vfsmount_lock when the first mount point is reached,
and holding onto it until the d_cache lookup is completed.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTEC
Make getcwd() fail with -ENOENT if the current working directory is
disconnected: the process is not asking for some previous name of that
directory but for the current name; returning a path meaningless in the
context of that process makes no sense.
Signed-off-by: Andreas Gruenbacher <[EM
Remove some duplicate code in generating the contents of /proc/mounts and
/proc/$pid/mountstats.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
---
fs/proc/base.c | 45 +++--
1 file changed, 15 insertions(+), 30 deletions(-)
--- a/f
e instead.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
---
fs/dcache.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1829,8 +1829,11 @@ global_root:
buffer++;
ke this one and
hide unreachable mount points from /proc/mounts.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
---
fs/dcache.c | 169 ++--
1 file changed, 98 insertions(+), 71 deletions(-)
--- a/fs/dcache.c
+++ b/fs/
In AppArmor, we are interested in pathnames relative to the namespace root.
This is the same as d_path() except for the root where the search ends. Add
a function for computing the namespace-relative path.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Reviewed-by: John Johansen &
(which it usually is), it will see all
mounts except for the rootfs.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
---
fs/namespace.c | 23 +--
fs/proc/base.c | 10 +-
2 files changed, 30 insertions(+), 3 deletions(-)
--- a/fs/namespace.c
+++
On Monday 16 April 2007 18:45, Christoph Hellwig wrote:
> You should provide intent information, yes - which your patch didn't :)
Well, the information implicitly provided is "no intent": In do_create() in
ipc/mqueue.c intents would be pretty pointless because the mqueue filesystem
is local. In fs
On Monday 16 April 2007 23:57, Alan Cox wrote:
> I don't believe the existing behaviour _IS_ a mistake.
So what would be the arguments why this behavior makes sense, other than
legacy?
For /proc/mounts, one could argue that the admin might want to see everything,
but then that's not actually tr
On Monday 16 April 2007 18:42, Randy Dunlap wrote:
> Please don't use the kernel-doc begin-marker "/**" when the comment block
> isn't in kernel-doc format.
Sigh, kernel-doc should improve things, not get in the way ...
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-mo
On Monday 16 April 2007 18:21, Christoph Hellwig wrote:
> But anyway, creating fake nameidata structures is not really helpful.
> If there is a nameidata passed people expect it to be complete, and
> if you pass them to an LSM people will e.g. try to look into lookup
> intents.
I don't actually ag
that struct in those places where a
full nameidata is not needed.
The entire patch is a little big so I'm only including the key parts here. The
complete version is here:
http://forgeftp.novell.com/apparmor/LKML_Submission-April_07/split-up-nameidata.diff
Signed-off-by: Andreas Gruenbach
ar vfsmount to vfs_create the files would
appear disconnected while they actually are kernel-internal objects. Use a
NULL vfsmount there to avoid that -- passing the kernel-internal vfsmount
there wouldn't help, anyway.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
---
fs/name
On Thursday 12 April 2007 11:58, Alan Cox wrote:
> > Third, sys_getcwd() shouldn't return disconnected paths. The patch checks
for
> > that, and makes it fail with -ENOENT in that case
>
> That is a fairly significant and sudden change to the existing
> kernel/user interface.
Well, this is not
1 - 100 of 112 matches
Mail list logo
