Package: coreutils;
Reported by: kalle <kalle <at> projektwerkstatt.de>
Date: Mon, 30 Oct 2017 18:35:01 UTC
Severity: normal
Tags: notabug, patch
Merged with 31043
View this message in rfc822 format
From: Assaf Gordon <assafgordon <at> gmail.com> To: kalle <kalle <at> projektwerkstatt.de>, 29069 <at> debbugs.gnu.org, control <at> debbugs.gnu.org Subject: bug#29069: info coreutils file permissions: improvements/bug-report Date: Mon, 30 Oct 2017 13:35:32 -0600
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
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.