permission wrt different types of files

hi

i'm trying to detailed information about what permissions do wrt
different types of files (directory,file,pipes,socket,devices,etc).
What are the correct behaviors.
I need a full table listing "all" combinations. (don't forget
suid,sticky bit,etc)
I found a lot of pages on this stuff, but no page has complete
information.
I need to write a test script.

Thanks

<perltcl@yahoo.com> wrote in message
news:1152031467.149394.102510@v61g2000cwv.googlegr oups.com

> I need a full table listing "all" combinations. (don't forget
> suid,sticky bit,etc)
> I found a lot of pages on this stuff, but no page has complete
> information.

http://www.yiluda.net/manual/linux/r...le:permissions

ynotssor wrote:
> <perltcl@yahoo.com> wrote in message
> news:1152031467.149394.102510@v61g2000cwv.googlegr oups.com
>
> > I need a full table listing "all" combinations. (don't forget
> > suid,sticky bit,etc)
> > I found a lot of pages on this stuff, but no page has complete
> > information.
>
> http://www.yiluda.net/manual/linux/r...le:permissions

what page has only info wrt file and directory, but not other types...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I hereby accuse perltcl@yahoo.com of stating:

>
> ynotssor wrote:
>> <perltcl@yahoo.com> wrote in message
>> news:1152031467.149394.102510@v61g2000cwv.googlegr oups.com
>>
>> > I need a full table listing "all" combinations. (don't forget
>> > suid,sticky bit,etc)
>> > I found a lot of pages on this stuff, but no page has complete
>> > information.
>>
>> http://www.yiluda.net/manual/linux/r...le:permissions
>
> what page has only info wrt file and directory, but not other types...

According to the linux VFS, everything *is* either a file or a directory. A
permission will have the same effect on a device node as on a file, i.e. if
it's +r you can read from it, and if it's +w you can write to it (+x is
meaningless).

- --
S. Tyler McHenry

http://www.nerdland.net/~tyler/info/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFEqqd8yhIpIIGf1i4RAjwEAJ9LrL5fiQEAIPm6ztWFsr 7XJv+hdgCdH91u
koZOTzNV9voeEx3wJRpn1BI=
=9kk4
-----END PGP SIGNATURE-----

<perltcl@yahoo.com> wrote in message
news:1152033655.328645.173340@j8g2000cwa.googlegro ups.com

>>> I need a full table listing "all" combinations. (don't forget
>>> suid,sticky bit,etc)
....
>> http://www.yiluda.net/manual/linux/r...le:permissions
>
> what page has only info wrt file and directory, but not other
> types...

In Unix/Linux, there *is* no other.

perltcl@yahoo.com writes:

>hi

>i'm trying to detailed information about what permissions do wrt
>different types of files (directory,file,pipes,socket,devices,etc).
>What are the correct behaviors.
>I need a full table listing "all" combinations. (don't forget
>suid,sticky bit,etc)
>I found a lot of pages on this stuff, but no page has complete
>information.
>I need to write a test script.

man 1p chmod

Now, why should someone write you " a full table listing "all"
combinations."?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Tyler McHenry wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> I hereby accuse perltcl@yahoo.com of stating:
> > ynotssor wrote:
> >> <perltcl@yahoo.com> wrote in message
> >> news:1152031467.149394.102510@v61g2000cwv.googlegr oups.com
> >>
> >> > I need a full table listing "all" combinations. (don't forget
> >> > suid,sticky bit,etc)
> >> http://www.yiluda.net/manual/linux/r...le:permissions
> >
> > what page has only info wrt file and directory, but not other types...
>
> According to the linux VFS, everything *is* either a file or a directory.

P'haps the OP is concerned about the subvarieties of file known as
"block special device", "character special device", "symbolic link",
and "unix socket". While all of these behave within the Unix
file/directory paradyme, they do exhibit differences in permission bit
values and interpretations.

[snip]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32) - WinPT 0.11.12

iD8DBQFEqsFWagVFX4UWr64RAvdeAKDRNd/AcQFBR0pcikzSGqaESYGZMwCg6mn2
8qYySYkgAT2OpvbkcWgOqUg=
=fagm
-----END PGP SIGNATURE-----

perltcl@yahoo.com wrote:
> ynotssor wrote:
>
>><perltcl@yahoo.com> wrote in message
>>news:1152031467.149394.102510@v61g2000cwv.google groups.com
>>
>>
>>>I need a full table listing "all" combinations. (don't forget
>>>suid,sticky bit,etc)
>>>I found a lot of pages on this stuff, but no page has complete
>>>information.
>>
>>http://www.yiluda.net/manual/linux/r...le:permissions
>
>
> what page has only info wrt file and directory, but not other types...
>

There really are no other types. The permission bits don't so much
have an effect depending on the file type, as what system call you
are making to that object. For example to use the readdir() system call
to locate a file in a directory, you need "x" (search) on that directory.
to read() a directory (say for "ls") you need "r" on that directory.

Now, to read or write to a socket or device file is no different. If you
use the read() and write() system calls you need "r" and "w" permission.

The special mode bits such as SUID have an effect on some system calls,
beyond just allowing access. For example SUID has no affect on
whether or not some file can be used by exec() (that's what "x"
is for), but if you are allowed to exec() a file, the EUID is changed
from the real UID to the UID (owner) of the file if SUID is set.

From this it should be clear that the extra bits have no special
effect for special file types such as sockets or FIFOs or devices
or even directories. It's just that you usually make different
system calls to directories than to other things. The normal rules
for all file system objects apply: "r" to read, "w" to write.

The only possible special case not normally found in the books
or on-line is that a file with the SGID bit on, if the filesystem
was mounted as "mount -o mand ...", means that manditory file
locking applies. Of course not all file system types support
that. But I mention it because if one process has open() a file
or socket or whatever, another may fail to open it.

For a pretty through review of file permissions and related
concepts see my "more than you really wanted to know" guide
at http://wpollock.com/AUnix1/FilePermissions.htm

-Wayne