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]
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

Powered by blists - more mailing lists