full-disclosure - M$ - so what should they do?

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] [day] [month] [year] [list]

Message-ID: <200406221559.i5MFxdmS015056@turing-police.cc.vt.edu>
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: M$ - so what should they do? 

On Mon, 21 Jun 2004 21:52:36 MDT, Bruce Ediger <eballen1@...st.net>  said:

> And you have to open them by path "/dev/null".  Just opening "null" won't
> hurt, unless the current directory happens to be "/dev".

Small nit:

Actually, this may or may not be true.  There is no *inherent* magic to
the /dev directory - it's merely the traditional place such things get put.
However, it doesn't matter *where* the file is -  it's still a *real* file
system entry and not an invisible magic entry...

Consider that this *will* work:

# cd ./tmp
# ls -l /dev/null
crw-rw-rw-  1 root root 1, 3 Jun 14 15:42 /dev/null
# mknod null c 1 3
# ls -l null
crw-r--r--  1 root root 1, 3 Jun 22 11:51 null

There you go - a 'null' device file in the current directory (Incidentally,
stopping this sort of thing is why many/most/all Unixoids support a
'nodev' option on the 'mount' command).....

The point remains that on Unixoid systems, it's done in 2 steps.  First,
the path is resolved down to a final target object (dealing with any /, ., or ..
that may be found along the way).  Either you get handed a permission error
along the way, or you're looking at an object that's visible to you.  At that
point, the *visible* opject is dealt with in an appropriate manner (regular file,
a pipe, a reference to a physical device, and so on).

(And yes, I *know* I glossed over a few details, such as the exact semantics
of traversing a directory that doesn't have both the r and x bits, and the
subtle distinction between the root inode of a mounted filesystem, and the
inode of the directory that's the mount point... :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040622/e0ae9c09/attachment.bin