Q: Permission checks for symbolic links in HP-UX 11.31 - HP UX

This is a discussion on Q: Permission checks for symbolic links in HP-UX 11.31 - HP UX ; Hi, could it be that HP-UX 11.31 (September Release) considers permissions for symbolic links, even though the manual page ln(1) claims otherwise? In Linux the permissions for symbolic links is always "a=rwx", while in HP-UX the umask masks off bits, ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Q: Permission checks for symbolic links in HP-UX 11.31

  1. Q: Permission checks for symbolic links in HP-UX 11.31

    Hi,

    could it be that HP-UX 11.31 (September Release) considers permissions for
    symbolic links, even though the manual page ln(1) claims otherwise?
    In Linux the permissions for symbolic links is always "a=rwx", while in HP-UX
    the umask masks off bits, like "go=-rwx". It looks as if a user of the
    category "other" (o) fails to access the file the link refers to if the
    correspondig permission bits on the _link_ are absent.

    My view of symbolic links (in an ideal world) would be somehow in-between:
    Write permissions on the symbolic link allows a process to modify the value of
    the link, while read permissions allow a process to read the value of the
    link. Thus accessing a file via a symbolic link would require read permissions
    on all intermediate links.

    Now that I don't heve HP-UX sources: How did HP-UX 11.31 implement access
    checking and traversing of symbolic links? The wrong way?


    HP technican's answer: As HP-UX uses "umask 0" by default, this issue isn't
    really a problem on a "standard installation".


    Regards,
    Ulrich

  2. Re: Q: Permission checks for symbolic links in HP-UX 11.31

    Ulrich Windl wrote:
    > could it be that HP-UX 11.31 (September Release) considers permissions for
    > symbolic links, even though the manual page ln(1) claims otherwise?


    I don't think so, they should be ignored.

    > It looks as if a user of the
    > category "other" (o) fails to access the file the link refers to if the
    > corresponding permission bits on the _link_ are absent.


    I don't see this, at least for "u": (Original 11.31 release)
    $ (umask 444; ln -s ~/hi.c . ) # even with 777
    $ ll hi.c
    l-wx-wx-wx 1 dhandly 18 Jan 10 19:26 hi.c@ -> /home/dhandly/hi.c
    $ more hi.c
    #include ...

+ Reply to Thread