Subject: Re: UFS chmod weirdness
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Holo.Rodents.Montreal.QC.CA>
Date: 12/22/1996 07:50:34
>> This appears to be intended to prevent non-root from setting sticky
>> bits (except on directories). However, it has the side effect that
>> given a file owned by non-root with its sticky bit set, then even
>> its owner cannot chmod that file without (irrevocably) clearing the
>> sticky bit.
>> Is it supposed to work this way? It produces some very odd-looking
>> failure messages from chmod(1).
Incidentally, the resulting failure (EFTYPE) is not one of the
documented-as-possible failures in the manpage for chmod(2).
> Hmm, sticky(8) says the following about directories. I assume your
> comments was more pointed at directories than at files, and in
> general the behavior is not much different anyway.
No, I was talking entirely about files. The code specifically exempts
directories from that check.
What happened was, I had a big tree of stuff, only some of which I
owned. I wanted to make sure the group write bits were set on all the
things I owned....
find . -type f -user mouse ! -perm 010/010 -print | xargs chmod g+w
(this is my private find, which has a souped-up -perm option that takes
a mask and a compare value.) The chmod fell over on four files, files
which proved to be mode 1444. I have no idea how they got that way,
but seeing those EFTYPE errors from chmod(1) got me curious, so I went
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B