Menu
▾
▴
#8 dos2unix on MacOS
W/R to the change triggered by "dos2unix changes ownership and permissions on the file - ID: 3327171":
For MacOS the option -DNO_CHOWN must be added to the compile time flags.
This is necessary because Darwin will create files with the file-owner-group set to the file-owner-group of the directory - EVEN if the caller is not a member of the group! Chowning *from* the group is ok, chowning *to* the group is not - and this will make unix2dos fail when it tries to restore the permissions.
To reproduce (assumes std setup, i.e. user not member of group wheel"):
$ echo hello >file
$ cp file /tmp
$ mv /tmp/file .
(This will create a file whose group is set to "wheel", because "/tmp" belongs to that group.)
$ dos2unix file
dos2unix: converting file file to Unix format ...
dos2unix: Failed to change the owner and group of temporary output file d2utmpkPAcQH: Operation not permitted
$ echo $?
1
$
Discussion
Anonymous
Hi,
Is this behaviour typical for MacOS, or is it just your installation?
What do you get when you type: "ls -ld /tmp"?
What is the output of command "uname -s"?
When I try it on Linux I see that "file" keeps it original group and owner. And these are the values of /tmp:
$ ls -ld /tmp
drwxrwxrwt 88 root root 16384 2011-11-29 07:56 /tmp
best regards,
Erwin
> Is this behaviour typical for MacOS, or is it just your installation?
I believe it is a MacOS property - from the open(2) manual page on MacOS 10.6: "When a new file is created, it is given the group of the directory which contains it."
> What do you get when you type: "ls -ld /tmp"?
$ ls -ld /tmp
lrwxr-xr-x@ 1 root wheel 11 16 Nov 16:29 /tmp -> private/tmp
$ ls -ld /private/tmp
drwxrwxrwt 7 root wheel 238 2 Dez 12:08 /private/tmp
> What is the output of command "uname -s"?
$ uname -s
Darwin
$
> When I try it on Linux I see that "file" keeps it original group and owner.
Apple's slogan is "Think different..." ;-)
MacOS is loosely based on the BSD family of Unices, which I seem to remember all have the "gid of new file=gid of directory containing it" philosophy. System V uses "gid of new file=(main)egid of process creating it" and Linux is somewhere inbetween in that you usually have System V semantics but you can use the SGID bit on a directory to get a BSD like behaviour.
Cheers,
Wolf
Hi,
I committed your proposed change to SVN and I provided a 5.3.2-beta1 version on my webpage.
See http://waterlan.home.xs4all.nl/dos2unix.html
Thanks for the report.
Can you check if it is OK?
regards,
Erwin
Hi Wolf,
As long as you are the owner of the file the group doesn't matter so much, is it?
If the file get's a new owner, than you have created the file in a directory which is not your own, but you do have write permission in that directory, if I understand correctly.
Could you run these commands for me, and mail me the output?
set -x
id
ls -ld ${PWD}
rm -f file
rm -f /tmp/file
echo hello >file
ls -l file
cp file /tmp
ls -l /tmp/file
mv /tmp/file .
ls -l file
perl -pli -e s/el/EL/ file
ls -l file
cat file
dos2unix file
ls -l file
set +x
I would also like to have to following information.
$ touch t.c
$ gcc -E -dM t.c > darwin.txt
Could you mail darwin.txt to waterlan@xs4all.nl ?
With the change another problem is created. When an administrator (root) comes along and converts files with dos2unix, they become unreadable by the original owner.
Hi Erwin,
> As long as you are the owner of the file the group doesn't matter so much, is it?
No, it should not matter, except if you have rather unusual mode/ownership settings to start with.
> If the file get's a new owner, than you have created the file in a directory which is not your own,
> but you do have write permission in that directory, if I understand correctly.
The owner (UID) does not change - just the group does. And yes, you do need write permission
for the directory.
Protocol of the requested commands:
bash-3.2$ id
+ id
uid=502(owner) gid=20(staff) groups=20(staff),402(com.apple.sharepoint.group.1),401(com.apple.access_screensharing),12(everyone),33(_appstore),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),100(_lpoperator),204(_developer)
bash-3.2$ ls -ld ${PWD}
+ ls -ld /Users/owner/tmp
drwxr-xr-x 3 owner staff 102 5 Dez 09:43 /Users/owner/tmp
bash-3.2$ rm -f file
+ rm -f file
bash-3.2$ rm -f /tmp/file
+ rm -f /tmp/file
bash-3.2$ echo hello >file
+ echo hello
bash-3.2$ ls -l file
+ ls -l file
-rw-r--r-- 1 owner staff 6 5 Dez 09:43 file
bash-3.2$ cp file /tmp
+ cp file /tmp
bash-3.2$ ls -l /tmp/file
+ ls -l /tmp/file
-rw-r--r-- 1 owner wheel 6 5 Dez 09:43 /tmp/file
bash-3.2$ mv /tmp/file .
+ mv /tmp/file .
bash-3.2$ ls -l file
+ ls -l file
-rw-r--r-- 1 owner wheel 6 5 Dez 09:43 file
bash-3.2$ perl -pli -e s/el/EL/ file
+ perl -pli -e s/el/EL/ file
bash-3.2$ ls -l file
+ ls -l file
-rw-r--r-- 1 owner staff 6 5 Dez 09:43 file
bash-3.2$ cat file
+ cat file
hELlo
bash-3.2$ dos2unix file
+ dos2unix file
dos2unix: converting file file to Unix format ...
bash-3.2$ ls -l file
+ ls -l file
-rw-r--r-- 1 owner staff 6 5 Dez 09:43 file
bash-3.2$ set +x
+ set +x
(Interesting: perl obviously creates a new copy, even though editing in place is requested!)
Wolf Geldmacher schreef, Op 5-12-2011 9:55:
> Hi Erwin,
>
>
> pls find enclosed the result of the tests you asked for in the form of a
> typescript protocol.
>
>
> I'll also add this (somewhat stripped down) to the SF page.
>
> As for the problem: The setting of the NO_CHOWN flag @ compile time was
> just a quick workaround for me to get my environment into working
> condition. Maybe the proper way to fix this is to make the call to chown
> use -1 as GID so that
> the group ownership is not touched?
>
> Cheers,
> Wolf
Hi Wolf,
Thanks for the transcript.
I was thinking of such a solution. In the C code I could leave the group alone when __APPLE__ is defined.
You are not a member of group 'wheel', so you can't change files to group 'wheel'. "chgrp wheel file" will also fail. Today this is normal behaviour (you can configure your system to allow it), but on Darwin you can you can change files to group wheel via /tmp.
Perl does not restore the original permissions in in-place mode. Perl does that only when it is executed by root. If you have root permissions you can try.
Dos2unix always tries to restore permissions during in-place conversion (old file mode). Not restoring original values could be destructive, or a security issue. Other users, who are member of the original group, but not of your primary group, are not able to read the file any more after the conversion. Or you make the file readable to users in your primary group, which are not member of the original group, who should not be able to read it. Or what if root does the conversion, then the file is not readable any more by anyone except root.
I was a bit in doubt if dos2unix should always restore permissions, or only when invoked by root. I chose the most secure option. Until now I didn't get any complaints yet. Is your problem a unique case (only happens when you move files from /tmp) or do you encounter this problem a lot on Darwin?
In new file mode, dos2unix creates a new file (obviously).
dos2unix -n file file
should work (if you have permission to remove the original file). But now you are explicitly asking to create a new file.
So I'm not sure yet if I should make an exception for Darwin. Perhaps it's inconvenient behaviour of the system, which you have to live with.
Erwin
Hi Wolf,
For now I removed the patch for Darwin. I think the default behaviour should not be changed. See my previous comment.
I'm thinking of adding a new option that disables the restoration of the original group/owner. But I'm not very fond of adding extra options. Especially when is this only a rare case. I guess that as long as you are not moving files from /tmp, you don't encounter the problem. But I have never worked on a MacOS machine, so I don't know.
best regards,
Erwin
Hi,
I reject this report for the reasons I described earlier. I also don't get any response any more.
Feel free to compile with -DNO_CHOWN in your own environment.
best regards,
Erwin Waterlander