|
Description
|
In Solaris 9 and 10, in.ftpd accepts the `site chmod' command (with an octal mode and
file name), but this has unexpected semantics - quite different from what chmod(1)
would do when invoked from a shell - when the file we are manipulating has a nontrivial
ACL:
===8<---
$ cd /some/test_directory
$ touch a
$ chmod 0440 a
$ ls -l a
-r--r----- 1 someuser somegrp 0 Aug 21 22:10 a
$ setfacl -m 'group:adm:rwx' a
$ ls -l a
-r--r-----+ 1 someuser somegrp 0 Aug 21 22:10 a
$ getfacl a
# file: a
# owner: someuser
# group: somegrp
user::r--
group::r-- #effective:r--
group:adm:rwx #effective:r--
mask:r--
other:---
$
--->8===
(So we have a file with a nontrivial ACL and with the mask bits equal to the group
owner bits, which is the common case. The customer's original example had been more
exotic, with mask and group owner bits initially different.) Now let us try to change
the permissions by using site chmod in an FTP session to this Solaris 9 system. NB
the test directory resides on a locally mounted UFS.
===8<---
$ ftp s9host
Connected to s9host.
220 s9host FTP server ready.
Name (s9host:someuser):
331 Password required for someuser.
Password:
230 User someuser logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd /some/test_directory
250 CWD command successful.
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 0
-r--r-----+ 1 someuser somegrp 0 Aug 21 22:10 a
226 Transfer complete.
66 bytes received in 0.0011 seconds (56.74 Kbytes/s)
ftp> site chmod 0664 a
200 CHMOD command successful.
ftp> dir a
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
-rw-r--r--+ 1 someuser somegrp 0 Aug 21 22:10 a
--->8===
Surprise! It's still read-only to the group owner ("somegrp").
===8<---
226 Transfer complete.
remote: a
57 bytes received in 0.0013 seconds (43.56 Kbytes/s)
ftp> quit
221-You have transferred 0 bytes in 0 files.
221-Total traffic for this session was 831 bytes in 2 transfers.
221-Thank you for using the FTP service on s9host.
221 Goodbye.
$
--->8===
So what has happened?
===8<---
$ ls -l a
-rw-r--r--+ 1 someuser somegrp 0 Aug 21 22:10 a
$ getfacl a
# file: a
# owner: someuser
# group: somegrp
user::rw-
group::r-- #effective:r--
group:adm:rwx #effective:rw-
mask:rw-
other:r--
$
--->8===
The site chmod 0664 command has set the user bits to rw- (as expected), the
other bits to r-- (as expected), and the *mask* bits, rather than the group
owner bits (which are unchanged at r--), to rw-. This is precisely the
POSIX 1003.1e (defunct) draft standard semantics of the chmod(2) system
call, unfortunately not currently correctly documented in man -s 2 chmod
(see CR 6316868 for that). But it differs from the semantics of the
chmod(1) commandline utility, which goes to extra lengths in this situation
to set *both* the group owner and the mask bits:
===8<---
$ chmod 0664 a
$ ls -l a
-rw-rw-r--+ 1 someuser somegrp 0 Aug 21 22:24 a
$ getfacl a
# file: a
# owner: someuser
# group: somegrp
user::rw-
group::rw- #effective:rw-
group:adm:rwx #effective:rw-
mask:rw-
other:r--
$
--->8===
This present behavior of in.ftpd is unexpected, mildly confusing, undocumented, and
arguably not particularly useful except as a classroom illustration of 1003.1e.
|
