zfs discuss - Feb 2010 - chmod behavior with symbolic links

Hi,

 

I know it''s documented in the manual, but I find it a bit strange
behaviour that chmod -R changes the permissions of the target of a
symbolic link.

 

This just really messed up my system, where I have a data directory, with a
backup of some Linux systems.

Within these Linux systems, there are some absolute links like ->
/usr/bin/bash

So, what I did, was set some NFSv4 ACLs recursively on this "data"
directory like:

chmod -R
A=group:admins:rwxpdDaARWcCos:fd-----:allow,group:it:rwxpdDaARWcCos:fd-----:allow
/array0/data

 

What I then found is /usr/bin/bash and a whole lot of other files in /usr/lib
/lib and /usr/sbin look like:

----------+  1 root    root      1019 Feb 22 14:31 bash

    group:admins:rwxpdDaARWcCos:------I:allow

    group:it:rwxpdDaARWcCos:------I:allow

 
>From here, I can only think of backing out the last update and updating
again.
 

I noticed the GNU chmod won''t change the ACL of the target.

 

Is there any reason for this behaviour?

Have I missed something?

 

Regards

John Ryan

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100222/674bb663/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5105 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100222/674bb663/attachment.bin>

>I know it''s documented in the manual, but I find it a bit strange
behaviour
>that chmod -R changes the permissions of the target of a
>symbolic link.
>
>Is there any reason for this behaviour?
>
Symbolic links do not have a mode; so you can''t chmod them; chmod(2) 
follows symbolic links (it was created before symbolic links existed).
Unfortunately, when symbolic links were created, they had an owner but
no relevant mode: so there''s a readlink, symlink, lchown but no lchmod.

I think a lchmod() would be nice, if only to avoid following them.

Casper

If you''re doing anything with ACLs, the GNU utilities have no
knowledge of ACLs, so GNU chmod will not modify them (nor will GNU ls
show ACLs), you need to use /bin/chmod and /bin/ls to manipulate them.

It does sound though that GNU chmod is explicitly testing and skipping
any entry that''s a link (at least when -R is present).  If lchmod
isn''t added, perhaps a flag to indicate ''don''t touch
symlinks'' would
be useful to add to /bin/chmod (changing the default behavior might be
a bit more complicated, though might be worth looking into).

On Mon, Feb 22, 2010 at 9:06 AM, Ryan  John <john.ryan at bsse.ethz.ch>
wrote:
> Hi,
>
>
>
> I know it?s documented in the manual, but I find it a bit strange behaviour
> that chmod ?R changes the permissions of the target of a symbolic link.
>
>
>
> This just really messed up my system, where I have a data directory, with a
> backup of some Linux systems.
>
> Within these Linux systems, there are some absolute links like ->
> /usr/bin/bash
>
> So, what I did, was set some NFSv4 ACLs recursively on this ?data?
directory
> like:
>
> chmod -R
>
A=group:admins:rwxpdDaARWcCos:fd-----:allow,group:it:rwxpdDaARWcCos:fd-----:allow
> /array0/data
>
>
>
> What I then found is /usr/bin/bash and a whole lot of other files in
> /usr/lib /lib and /usr/sbin look like:
>
> ----------+? 1 root??? root????? 1019 Feb 22 14:31 bash
>
> ??? group:admins:rwxpdDaARWcCos:------I:allow
>
> ??? group:it:rwxpdDaARWcCos:------I:allow
>
>
>
> From here, I can only think of backing out the last update and updating
> again.
>
>
>
> I noticed the GNU chmod won?t change the ACL of the target.
>
>
>
> Is there any reason for this behaviour?
>
> Have I missed something?
>
>
>
> Regards
>
> John Ryan
>
>
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
>