If I create a file as an unprivileged user, and change the permissions mode to 400
, it's seen by that user as read-only, correctly:
$ touch somefile
$ chmod 400 somefile
$ [ -w somefile ] && echo rw || echo ro
ro
All is well.
But then root comes along:
# [ -w somefile ] && echo rw || echo ro
rw
What the heck? Sure, root can write to read-only files, but it shouldn't make a habit of it: Best Practice would tend to dictate that I should be able to test for the write permission bit, and if it's not, then it was set that way for a reason.
I guess I want to understand both why this is happening, and how can I get a false return code when testing a file that doesn't have the write bit set?
4.1.2(1)-release
) and RHEL7 (4.2.46(2)-release
). – Rich May 3 '18 at 1:54/etc/dhcp/dhcpd.conf
, which is owned by root. I'm using the vendor-supplieddhcpd
. Total disaster, huh? The file is checked into RCS, I'm automating use ofrcsdiff
,ci
andco
because we have operators that need to ... operate. The permission bit check (-w
, as detailed bytest(1)
) was going to be a first line of failure, working on the basis thatci -u
leaves a file read-only. I'm ditching that and going straight torcsdiff -q
and checking$?
. Undisastrousdhcpd
? It would be owned bydhcpd
. – Rich May 3 '18 at 17:34bash
andtest
led me to believe that's what[ -w
is for. – Rich May 3 '18 at 18:18