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  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:	Sat, 19 Jan 2008 16:55:53 -0600
From:	"Steve French" <>
To:	"Andi Kleen" <>
Cc:	simo <>,,,
Subject: Re: [linux-cifs-client] [PATCH] Remove information leak in Linux CIFS clientg

On Jan 19, 2008 4:30 PM, Andi Kleen <> wrote:
> On Sat, Jan 19, 2008 at 04:06:57PM -0600, Steve French wrote:
> > The access denied message in the dmesg log reveals no more information
> > than strace on stat of a local file does (which also returns access
> You can't strace a process you don't own. And you might not be able
> to access the directory below which the file is.

If you can't access the directory that the file is in then you get
access denied on stat of the file (local over ext3 or remote over
cifs) - it does not tell you anything about whether the file existed
or not.  If you do "stat
/mnt/dir-with-0700-perm/file-which-does-not-exist"  I get access
denied.  I don't think that it really tells you anything interesting
since the same error comes back whether or not the file existed.
Other unexpected errors (e.g. -EIO) should be logged because they
indicate possibly severe problems with the network, but also don't
tell you anything about whether the file exists.

> Logging the path would be only safe if you determine that the
> file and all its parent directories were world read (and accessable)able,
> but that would be probably difficult.

If the parent of the parent were not readable/accessable then you
would not have gotten this far (the stat of the parent directory
rather than the file would have returned the error).  If the parent
were readable then the access denied on stat is the same over cifs and
ext3 - and the logging of the error only occurs in cases like EIO in
which e.g. the network has crashed (but you can't tell from the error
whether the file exists or not).  I don't mind taking out the path
name from the logging of EIO in this case but it could make debugging
harder if we ever hit a strange bug.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists