This test below: 11 dir_writeable() 12 { 13 printf "" > "$1"/.test.$$ 2>/dev/null && rm "$1"/.test.$$ 14 } 15 prints an annoying message to stdout when running with a read only root filesystem. This is due to the redirection of 2> not working for errors in the current shell where the first redirection fails >
Try emerging udev and see if the warning is still there -- the postmount script has been worked on recently.
I will do, but this also /etc/init.d/bootmisc also. I believe that test -w on a mount point as root or directory will return the correct value. I have tested this on a couple of mountpoints and the correct value is returned when test -w on a directory and or mount point is used. There really isn't a need to reinvent the wheel as it were by creating a temporary file when this is not needed. (I am tempted to say that there is no need to leave smoking guns lying around, but I wont :) )
Nope. Still there.
udev -158 - still present.
As can be seen in udev Changelog, that printf "" > ... was done due to Selinux compatibility (See Bug 317573). What would be your solution to that printf error? Does swapping the two redirections help?
It was interesting to see the reason for that being added. Thanks for that > What would be your solution to that printf error? > Does swapping the two redirections help? I will try swapping, but as far as I can tell, the error comes the the current shell, with PID $$. Unless stderr for the current shell is redirected, which I forget how this is done, then the error will still be here. If, however, a different command was used to create the file/directory then the error could be redirected. \
This isn't the correct solution for bug #317573. Just use the correct dir_writable from bootmisc, which works correctly (ie. creates a directory not a file) (In reply to comment #6) > It was interesting to see the reason for that being added. Thanks for that > > What would be your solution to that printf error? > > Does swapping the two redirections help? Sorry, I use zsh, and printf is a built in. As you are execing /usr/bin/printf, try doing, if you wish to create a file and NOT a dir touch "$1"/.test.$$ 2>/dev/null && rm ?-f? "$1"/.test.$$ which is what you really want anyway - both seem to be from core utils zsh % q belongs /usr/bin/printf sys-apps/coreutils (/usr/bin/printf) zsh linux % q belongs /usr/bin/touch sys-apps/coreutils (/usr/bin/touch) But you can just remove those 3 lines and use the correct code from /etc/init.d/bootmisc:dir_writeable.
(In reply to comment #7) > This isn't the correct solution for bug #317573. Just use the correct > dir_writable from bootmisc, which works correctly (ie. creates a directory not > a file) udev used a copy of dir_writable from bootmisc just before fixing bug #317573. So this bug stated, that SELinux forbids creating directories in this case and just allows creating files (which is the only thing we want to do later). So it seems obvious to just check this. > (In reply to comment #6) > > It was interesting to see the reason for that being added. Thanks for that > > > What would be your solution to that printf error? > > > Does swapping the two redirections help? > > Sorry, I use zsh, and printf is a built in. As you are execing /usr/bin/printf, > try doing, if you wish to create a file and NOT a dir > > touch "$1"/.test.$$ 2>/dev/null && rm ?-f? "$1"/.test.$$ Well, printf is used, as it seems to be a builtin in a posix-compliant shell. The goal is to avoid calling external programs like touch. > > But you can just remove those 3 lines and use the correct code from > /etc/init.d/bootmisc:dir_writeable. for reason why not use this, read above.
Was wrong about printf. I don't use bash much. The problem in anycase is that the file is being created by the shell, by the redirection. Something like this will work: rm -f "$1"/.test.$$ touch "$1"/.test.$$ 2>/dev/null && rm "$1"/.test.$$
> Well, printf is used, as it seems to be a builtin in a posix-compliant shell. > The goal is to avoid calling external programs like touch. > > > > > But you can just remove those 3 lines and use the correct code from > > /etc/init.d/bootmisc:dir_writeable. > for reason why not use this, read above. > I have read above, and the implementation is still incorrect.
So, to get to an end of that discussion: Did anyone test this command (as I suggested already in comment #5): # printf "" 2>/dev/null > "$1"/.test.$$ && rm "$1"/.test.$$ For me this does not print an error for a ro-directory, as stderr is already /dev/nulled.
I believe that the entire filesystem is read only. For security reasons, perhaps root NFS, or other reasons that I am not able to disclose at this juncture, the root FS is read only. The code is incorrect as the actual shell fails in this case. ie. try again in the failure case, not where you expect success. (In reply to comment #11) > So, to get to an end of that discussion: > Did anyone test this command (as I suggested already in comment #5): > # printf "" 2>/dev/null > "$1"/.test.$$ && rm "$1"/.test.$$ > > For me this does not print an error for a ro-directory, as stderr is already > /dev/nulled. >
(In reply to comment #12) > I believe that the entire filesystem is read only. For security reasons, > perhaps root NFS, or other reasons that I am not able to disclose at this > juncture, the root FS is read only. The code is incorrect as the actual shell > fails in this case. Yes, but it fails where stderr is already redirected, so the error message gets written there. > > ie. try again in the failure case, not where you expect success. > I did already test with a ro filesystem, but here is a log of a re-done test (with both bash and dash shell): bash # mount /mnt/cdrom bash # dir_writable() { printf "" 2>/dev/null > "$1"/.test.$$ && rm "$1"/.test.$$; } bash # dir_writable / && echo writable writable bash # dir_writable /tmp/ && echo writable writable bash # dir_writable /mnt/ && echo writable writable bash # dir_writable /mnt/cdrom/ && echo writable bash # dash # PS1="dash # " dash # dir_writable() { printf "" 2>/dev/null > "$1"/.test.$$ && rm "$1"/.test.$$; } dash # dir_writable / && echo writable writable dash # dir_writable /mnt/cdrom/ && echo writable dash # dir_writable /mnt/ && echo writable writable
I believe that this might be a bash feature. What is the reason for putting the 2> first may I ask? (In reply to comment #13) > (In reply to comment #12) > > I believe that the entire filesystem is read only. For security reasons, > > perhaps root NFS, or other reasons that I am not able to disclose at this > > juncture, the root FS is read only. The code is incorrect as the actual shell > > fails in this case. > Yes, but it fails where stderr is already redirected, so the error message gets > written there. > > > > > ie. try again in the failure case, not where you expect success. > > > > I did already test with a ro filesystem, but here is a log of a re-done test > (with both bash and dash shell): > > bash # mount /mnt/cdrom > bash # dir_writable() { printf "" 2>/dev/null > "$1"/.test.$$ && rm > "$1"/.test.$$; } > bash # dir_writable / && echo writable > writable > bash # dir_writable /tmp/ && echo writable > writable > bash # dir_writable /mnt/ && echo writable > writable > bash # dir_writable /mnt/cdrom/ && echo writable > bash # dash > # PS1="dash # " > dash # dir_writable() { printf "" 2>/dev/null > "$1"/.test.$$ && rm > "$1"/.test.$$; } > dash # dir_writable / && echo writable > writable > dash # dir_writable /mnt/cdrom/ && echo writable > dash # dir_writable /mnt/ && echo writable > writable >
(In reply to comment #14) > I believe that this might be a bash feature. What is the reason for putting the > 2> first may I ask? > Well, as far as I know, posix shells apply one redirection after another, in order of appearance on the commandline. (So it is possible to switch stdout and stderr via # cmd 3>&1 1>&2 2>&3 3>&- ) So my guess for dir_writable is that the shell writes to current stderr when it fails to open the stdout redirection. Another alternative that could be to redirect stderr and inside that redirection, run printf and rm. dir_writable() { { printf "" > "$1"/.test.$$ && rm "$1"/.test.$$; } 2>/dev/null; } But to come to the main point: Which shell does interprete the version of comment #13 wrong?
> But to come to the main point: Which shell does interprete the version of > comment #13 wrong? > It is bash, but I it is related to the USE flags. I didn't get around to looking at bash, but in any case zsh always prints and error. Is there a doc that describes the precedent of redirection, as these MUST be setup before the exec??(2). Is this feature documented in the POSIX standard? Sorry for taking so long, I didn't bother with the problem as it was flag related, probably some optimisation that has exposed a problem. You can change it to wont fix or watever.
Ok, to reproduce the ordering problem ie 2>&1 message with BASH the following flags do it on x86_64: -O3 -mssse3 -march=atom -mfpmath=sse -fomit-frame-pointer -floop-parallelize-all -fgcse-after-reload -pipe (I only realised it was a flag problem when I started playing around with some graphite features and discovered the nature of the problem changed)
Changed code to run touch && rm in udev-164.
