bug#29069: info coreutils file permissions: improvements/bug-report

[Assaf Gordon]

tag 29069 notabug
stop

Hello,

On 2017-10-30 02:38 PM, kalle wrote:
> here some improvement proposals/bug report on info coreutils file 
> permissions:
>
> -in my opinion it would be good to explain the general idea bihind 
> the file permissions a bit more. what the issues are etc. Elese one 
> doesn't really understand, what all the detailed fuss is about. -why
> is running a file considered different  from reading one? Fact is,
> that this point underlies the concept of symbolic mode with it's 
> `rwx'. -

There is a trade-off between being a full-blown unix tutorial and a
manual for coreutils.

There are many good tutorials and guides available in books and online,
e.g. https://wiki.debian.org/Permissions .

To make this discussion more concrete, it would help if you send 
specific patches for the paragraph you'd like to change, with suggested 
wording.

> 27.1,end of the first section: add the sentence "They have a 
> different meaning, according to wether they are directories or not"

Each relevant bullet points in that page end with "... for Directories,
this means [...]".

https://www.gnu.org/software/coreutils/manual/html_node/Mode-Structure.html

> 27.2.4, part "or already had execute permission": had execute 
> permission for which user category? for the one in question or for 
> any?

Any category.

The last sentence in that page says:
"gives all users permission [...]  if anyone could execute them before".

https://www.gnu.org/software/coreutils/manual/html_node/Conditional-Executability.html

> -explain more fundamentally the relationship between file permission
> rights and the rights of the corresponding directory , for example
> regarding to deletion: who has the right to delete file /b/a? users
> with writing permission on a AND those withrmission on b?

I think this is a good suggestion (though perhaps not specific to
coreutils).

We recently had a related discussion about that in 'sed',
where users were surprised that "sed --inplace" can modify a read-only file.
https://lists.gnu.org/archive/html/bug-sed/2017-06/msg00000.html

Similarly on gawk:
https://lists.gnu.org/archive/html/bug-gawk/2015-06/msg00000.html


> 27.4: wouldn't it be better to talk about 'operators _in_ numeric
> mode' rather than from an 'operator numeric mode', since "numeric
> mode" is an atrribute?

(I'll leave this to native English speakers)

> -27.3: is there an info/man-document, where binary,
> octal, hex-numbers are explained? If, it should be referred to. If 
> not, shouldn't there be one (and where would it fit in? ) ?-- I
> could write the text...Since this documentation assumes the knowledge
> of it..

Not sure this belongs in the coreutils manual,
however if you send a patch that would go a long way towards considering 
it for inclusion.

For comparison, I see that "chmod" manual page in OpenBSD, FreeBSD and
POSIX mention octal code values but do not explain with octal is.
The reader is expected to either use them as-is, or search for more 
details elsewhere.

https://man.openbsd.org/chmod.1
https://www.freebsd.org/cgi/man.cgi?query=chmod
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html

>
-27.5: it is said, that "a command like `chmod' does not
> affect the set-user-id, unless […] sets them in a numeric mode".But
> also, the example states that `chmod 0755' or `mkdir -m 0755'
> doesn't change set-user/group-id- bits.
>
> For me, this doesn't fit 
> together,since the `0' in `0755' explicitly sets all special mode 
> bits to zero.

There is some subtlety here, which perhaps can be explained better 
(patches are welcomed!).

Setting (=turning on) sticky/setuid/setgid bits using the 4th octal 
digit works as expected (i.e. chmod 4775 DIR).

In GNU's chmod(1), setting the 4th digit to zero *does not* clear those 
bits, it preserves them (i.e. does not change them if they are set).
To clear them, one needs to specify *five* octal digits: 00755.

This is explained in the second paragraph of section 27.5:
"Therefore, a command like chmod does not affect the set-user-ID or 
set-group-ID bits of a directory unless the user specifically mentions 
them in a symbolic mode, or uses an operator numeric mode such as 
‘=755’, or sets them in a numeric mode, or clears them in a numeric mode 
that has **five or more** octal digits."
https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

The last paragraph on said page also mentions:
"The GNU behavior with numeric modes of four or fewer digits is intended 
for scripts portable to systems that preserve these bits; the behavior 
with numeric modes of five or more digits is for scripts portable to 
systems that do not preserve the bits."

The wording could also be improved in section "27.3 Numeric Modes", 
which only mentions this in passing:
  "However, modes of five digits or more, such as ‘00055’,
   are sometimes special. See Directory Setuid and Setgid."
https://www.gnu.org/software/coreutils/manual/html_node/Numeric-Modes.html



> -27.5,last section, it says: "this behavior is a GNU 
> extension". Which behavior is meant?

This refers to the preceding paragraph, dealing with "if you want to 
clear these bits".

The behavior differs from other systems (e.g. FreeBSD),
where "chmod 0775" indeed clears the suid bit.


> greetings, kalle

Thank you for raising these issues.

If you'd like to suggest better wordings, please do send a patches
(preferably one patch for each section/topic).

I'm marking this as "not-a-bug", but keeping it open
until we either improve these items or decide to keep them as-is.

regards,
 - assaf