paulr@sequent.UUCP (Paul Reger) (11/15/89)
Why can't you change the filemodes of a symbolic link ? :
% echo > some_file
% chmod 321 some_file
% ls -l some_file
--wx-w---x 1 paulr 0 Nov 14 09:37 some_file*
% ln -s some_file some_link
% ls -l some_link
lrwxr-xr-x 1 paulr 9 Nov 14 09:38 some_link -> some_file*
% chmod 222 some_link
% ls -l some_file
-rwxrwxrwx 1 paulr 0 Nov 14 09:37 some_file*
% umask 000
% rm some_link
% ln -s some_file some_link
% ls -l some_file some_link
-rwxrwxrwx 1 paulr 0 Nov 14 09:37 some_file*
lrwxrwxrwx 1 paulr 9 Nov 14 09:38 some_link -> some_file*
% chmod 222 some_link
% ls -l some_file some_link
--w--w--w- 1 paulr 0 Nov 14 09:37 some_file
lrwxrwxrwx 1 paulr 9 Nov 14 09:38 some_link -> some_file
It appears that chmod changes the object that is pointed to, not the
pointer. Further, umask is meaningful to creation of the link.
But I could not find anyway to change the filemodes of the link...
Tried looking in the fine manual. Found no reference.
tia,
paulr (Paul Reger)
Sequent Computer Systems, Beaverton Oregon
{uunet,ucbvax!rutgers!ogccse}!sequent!paulr
--
paulr (Paul Reger)
Sequent Computer Systems, Beaverton Oregon
{uunet,ucbvax!rutgers!ogccse}!sequent!paulrperry@ccssrv.UUCP (Perry Hutchison) (11/15/89)
In article <24818@sequent.UUCP> paulr@sequent.UUCP (Paul Reger) writes: > Why can't you change the filemodes of a symbolic link ? : Another candidate for the Frequently Asked Questions list. There is no need to set the permissions of a symbolic link, because they are never used. Hard links have existed for a long time, but symbolic links are a more recent development. It has always (at least since 6th edition) been the case that the permissions belong to the file, and are not affected by which name (link) is used to access it. Symbolic links continue to behave in this same way. That a symbolic link even has its own set of permissions is largely an artifact of the implementation. Perhaps someday ls will be revised to omit them, since they are meaningless (and hence to display them is confusing). -- The "From" address in the header does not work. This does: ... tektronix!sequent!ccssrv!perry
cpcahil@virtech.uucp (Conor P. Cahill) (11/16/89)
In article <24818@sequent.UUCP>, paulr@sequent.UUCP (Paul Reger) writes: > Why can't you change the filemodes of a symbolic link ? : Because the modes of the link are never used. Restricting the write access on the link file does not restrict the write access on the file that it is linked to. That is why there is no lopen(), or lchmod() system call (would be similar to lstat()). -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+
mario@r3.cs.man.ac.uk (11/18/89)
In article <1989Nov16.004352.6195@virtech.uucp> Conor P. Cahill writes: >> Why can't you change the filemodes of a symbolic link ? : > >Because the modes of the link are never used. Restricting the write >access on the link file does not restrict the write access on the >file that it is linked to. That is why there is no lopen(), or lchmod() >system call (would be similar to lstat()). But a symbolic link contains information (the path where the file can really be found). So why can't I protect that information in the same way as I can protect all other information in the system? --no read permission would prevent you from finding what the symbolic link pointed to --no search(execute) permission would prevent you from following the symbolic link, and --if you could open the symbolic link for writing (say, to redirect the link without removing it), no write permission would prevent you from doing that too. All seems fairly obvious (except maybe the last point; maybe something deep depends on symbolic links being immutable; also, you'd need to extend open() to open the link not the target). So why isn't it like this? Mario Wolczko ______ Dept. of Computer Science Internet: mario@cs.man.ac.uk /~ ~\ The University USENET: mcvax!ukc!man.cs!mario ( __ ) Manchester M13 9PL JANET: mario@uk.ac.man.cs `-': :`-' U.K. Tel: +44-61-275 6146 (FAX: 6280) ____; ;_____________the mushroom project___________________________________
merlyn@iwarp.intel.com (Randal Schwartz) (11/19/89)
In article <24818@sequent.UUCP>, paulr@sequent (Paul Reger) writes: | Why can't you change the filemodes of a symbolic link ? : Two parts to the answer: (1) you can't, but luckily (2) you don't need to. The bits are never looked at. Don't worry, B happy. (Suprisingly, the *last* time I heard this topic brought up was while *I* was at Sequent; I was employee #64 there...) Just another <something> hacker, -- /== Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ====\ | on contract to Intel's iWarp project, Hillsboro, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!uunet!iwarp.intel.com!merlyn | \== Cute Quote: "Welcome to Oregon... Home of the California Raisins!" ==/
cpcahil@virtech.uucp (Conor P. Cahill) (11/23/89)
In article <363@m1.cs.man.ac.uk>, mario@r3.cs.man.ac.uk writes: > In article <1989Nov16.004352.6195@virtech.uucp> Conor P. Cahill writes: > >> Why can't you change the filemodes of a symbolic link ? : > > > >Because the modes of the link are never used. Restricting the write > >access on the link file does not restrict the write access on the > >file that it is linked to. That is why there is no lopen(), or lchmod() > >system call (would be similar to lstat()). > > But a symbolic link contains information (the path where the file can > really be found). So why can't I protect that information in the same > way as I can protect all other information in the system? [things one could do with symbolic link permission bits deleted] Not that I was there when symbolic links were designed, but here goes: The symbolic link mechanism is designed to supplement the hard link mechanism wheree the hard link mechanism was not sufficient (like between file systems). The hard link has only 1 set of permission bits, reguardless of the name used to access the file. Since the symbolic link has it's own inode, the only way to have it appear the same as a hard link is to ignore the permission bits of the symbolic link file and use the permission bits of the file it points to. -- +-----------------------------------------------------------------------+ | Conor P. Cahill uunet!virtech!cpcahil 703-430-9247 ! | Virtual Technologies Inc., P. O. Box 876, Sterling, VA 22170 | +-----------------------------------------------------------------------+