On Mon, 15 Sep 2008 11:22:41 +0200 Erik Rossen <ros...@rossen.ch>
wrote:
> On Tue, Sep 02, 2008 at 10:48:30AM -0400, Michael Stone wrote:
> > On Tue, Sep 02, 2008 at 03:50:16PM +0200, Erik Rossen wrote:
> > >But it would be so much more elegant if chmod just Did The Right
Thing.
> >
> > It's certainly arguable whether adding another non-standard flag is
the
> > Right Thing when it's fairly trivial to get the result in a more
> > portable fashion using find(1).
>
> It seems that the FreeBSD people think that making a change to the
> filesystem only when necessary is The Right Thing. But I guess that
> argument carries no weight in GNU. ;-)
>
> > >Can I ask you to pass along this wishlist item to upstream and
maybe ask
> > >them why ctime must be modified even when the permissions are
not? I
> > >would really like to know why.
> >
> > Upstream monitors the debian bug logs and will presumably chime in
if
> > interested. I vaguely recall that people want these utilities to
act
> > even if not strictly necessary because of possible side effects
for
> > extended attributes.
> >
> > Mike Stone
>
> I took your advice (paraphrased: "try another tool") and I now have
> three options for fixing file permissions without disturbing the file
> system too much:
>
> 1. find + chmod : classic but ugly
>
> 2. cfengine : Does The Right Thing, but difficult to do as a one-
liner
> unless you are already using cfengine for other stuff
>
> 3. setfacl -R : nice. Does The Right Thing as a fairly simple one-
liner
>
> setfacl is kind of interesting. Even if the filesystem is mounted
> without extended ACLs enabled, it works for setting the POSIX ACLs
and
> it Does The Right Thing. For example, I can do
>
> setfacl -R -m u::rwX,g::rwX,o:rX shares/
>
> to fix every file and directory in "shares" to be readable, and
writable
> only by the owner and group of shares. And if I run the same command
> again, stat shows that the ctime has not changed unless it was
necessary
> to modify the permissions of a file or directory.
>
> I am pretty happy about this solution and I intend to use it in cases
> where there is a integrity-checker in place and no cfengine.
>
> But while doing my tests, I noticed something strange about setfacl:
if
> the filesystem is mounted with extended ACLs enabled (on a ext3 fs),
it
> is possible to use setfacl to make changes to file permissions and
CTIME
> IS NEVER MODIFIED EVEN IF PERMISSIONS ARE MODIFIED. I thought that
this
> was supposed to be impossible, but perhaps this is a known side-
effect
> ("feature") of activating extended ACLs on ext3.
>
> Can anyone else confirm this? I am running etch with an ext3
filesystem
> that was created in June 2008. This is my "uname -a":
>
> Linux mango 2.6.18-6-vserver-686 #1 SMP Mon Aug 18 11:11:15 UTC
2008 i686 GNU/Linux
>
I have another use-case for only attempting to make a change with chmod
if it is really necessary.
In a Debian postinst script (for VDR in this particular case) the
ownership of a directory (/var/lib/video) is changed - however I have
moved /var/lib/video to be a symlink to an NFS server. The permissions
are already set correctly, but as root can not (in this case) change an
NFS mounted file system, the chmod fails, even though it wanted to
change the owner to be the same as it already was.
A switch for chmod to say --only-if-needed or some such would avoid
this being an issue
John
