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/msg0.html

Similarly on gawk:
https://lists.gnu.org/archive/html/bug-gawk/2015-06/msg0.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, 

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

[kalle]

hello,
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'.
-27.1,end of the first section: add the sentence "They have a different
meaning, according to wether they are directories or not"
-27.2.4, part "or already had execute permission": had execute
permission for which user category? for the one in question or for any?
-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?
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?
-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..
-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.
-27.5,last section, it says: "this behavior is a GNU extension". Which
behavior is meant? And if it concerns the whole section 27.5, it should
be put right at the beginning.

greetings,
kalle

bug#29038: df hangs on fifos/named pipes

[Stephane Chazelas]

2017-10-30 09:53:01 -0700, Pádraig Brady:
[...]
> I pushed my change with the comments fixed up.
> 
> I thought about O_NONBLOCK and O_PATH but thought these might not
> induce or wait for the auto mount to occur.
[...]

Note that:

df /dev/watchdog

as root still causes the system to reboot on Linux. Not a POSIX
conformance issue as the behaviour is unspecified for device
files without a mounted file system on, but still not ideal.

The point is that opening files has or can have side effects and
df is not *meant* to open files.

I would think that automounting directories assuming we do want
it to happen should be enough unless someone can come up with a
realistic use case where non-directory files are being
automounted (and assuming that's possible).

-- 
Stephane

bug#29038: df hangs on fifos/named pipes

[Pádraig Brady]

On 29/10/17 23:16, Paul Eggert wrote:
> Pádraig Brady wrote:
> 
>> I suppose we could stat() and if that succeeds && !fifo, only then call 
>> open() ?
>> Patch to do that is attached.
> 
> Better is to use open with O_NONBLOCK, as this avoids interpreting the file 
> name 
> twice in the usual case. Better yet is to use O_PATH if available, as this 
> avoids interpreting the file name twice even when the file is unreadable or 
> is a 
> FIFO that would block. Also, the comment just before the code should be 
> changed 
> to match the altered code. Proposed followup patch attached.
> 
> It is puzzling that df calls fstat or stat, when it should just be calling 
> fstatfs or statfs. But that is a different matter.

I pushed my change with the comments fixed up.

I thought about O_NONBLOCK and O_PATH but thought these might not
induce or wait for the auto mount to occur.

thanks for the review,
Pádraig

marking this as done...

bug#28970: Fwd: unrecognized file system type 0x794c7630 for ‘/var/log/syslog’.

[Bernhard Voelker]

unarchive 22151 28970
forcemerge 22151 28970
stop

On 10/24/2017 06:33 PM, Brad Lowe wrote:
> Ran this on docker:
> https://github.com/bprodoehl/docker-turnserver
> 
> 
> [brad@docker2 ~]$ docker logs turn-server
> *** Running /etc/my_init.d/00_regen_ssh_host_keys.sh...
> *** Running /etc/rc.local...
> *** Booting runit daemon...
> *** Runit started as PID 7
> tail: unrecognized file system type 0x794c7630 for ‘/var/log/syslog’.
> please report this to bug-coreutils@gnu.org. reverting to polling

Thanks, this is already fixed in coreutils >= 8.25.

Have a nice day,
Berny

bug#28763: docbug (stat -t): missing field names in docs(manpage) for 'stat -t'

[Bernhard Voelker]

On 10/12/2017 08:51 AM, Assaf Gordon wrote:
> Attached an updated patch.

+1

Thanks & have a nice day,
Berny

bug#29062: PRINTF

[Eric Blake]

On 10/30/2017 01:46 AM, Assaf Gordon wrote:

> 
> This is not a relevant mailing list for such questions.

One more point - attaching a screenshot of plain text is wasteful of
bandwidth; it's better to copy-and-paste relevant text content, rather
than forcing people to transcribe the screenshot.

Another observation:

> int main(){
> typedef struct me {
> char str[8];
> int a;
> int b;
> }m;
> m a;
> 
> #include 

Mid-function includes like this are almost never going to work the way
you expect.  #includes should always be at the file scope.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#29038: df hangs on fifos/named pipes

[Stephane Chazelas]

2017-10-29 23:16:50 -0700, Paul Eggert:
> Pádraig Brady wrote:
> 
> >I suppose we could stat() and if that succeeds && !fifo, only then call 
> >open() ?
> >Patch to do that is attached.
> 
> Better is to use open with O_NONBLOCK, as this avoids interpreting the file
> name twice in the usual case.

That would still have the unwanted side effect of instantiating
(and kill thereafter) the pipe when opening a fifo that has a
writer and no reader.

As in, if some process does a fd = open("fifo", O_WRONLY)

The "df fifo" would cause that open() to return, and the next
write() to it possibly cause a SIGPIPE because df is already
gone.

It's different for O_DIRECTORY as the open() would fail on
fifos (it also fails if you don't have read permission,
which is another advantage of using O_PATH I suppose)


> Better yet is to use O_PATH if available, as
> this avoids interpreting the file name twice even when the file is
> unreadable or is a FIFO that would block.

Note that according to the man page, fstat() on fds open with
O_PATH only works since Linux 3.6. Note that we're already
interpreting the file path twice as we're not using fstatfs (as we
wouldn't want to cause a "too many open files" situation I
suppose by keeping all the files open before we get to the
second phase).

[...]
> It is puzzling that df calls fstat or stat, when it should just be calling
> fstatfs or statfs. But that is a different matter.

I suppose that's because it needs to determine if the file is a
device file or not as for device files where a fs is mounted, it
needs to report details for that fs as opposed to the fs the
device file is on.

-- 
Stephane

bug#29038: df hangs on fifos/named pipes

[Paul Eggert]

Pádraig Brady wrote:


I suppose we could stat() and if that succeeds && !fifo, only then call open() ?
Patch to do that is attached.


Better is to use open with O_NONBLOCK, as this avoids interpreting the file name 
twice in the usual case. Better yet is to use O_PATH if available, as this 
avoids interpreting the file name twice even when the file is unreadable or is a 
FIFO that would block. Also, the comment just before the code should be changed 
to match the altered code. Proposed followup patch attached.


It is puzzling that df calls fstat or stat, when it should just be calling 
fstatfs or statfs. But that is a different matter.
From c02f0e6009d7d77ee7a8e1299e03ca10a477c9e4 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sun, 29 Oct 2017 23:09:49 -0700
Subject: [PATCH] df: improve fix for FIFOs

* src/df.c (main): Use O_PATH if available.  Otherwise,
use O_NONBLOCK.  Either way, this avoids the need to
interpret the file name twice.
---
 src/df.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/src/df.c b/src/df.c
index ee04d51..cab1958 100644
--- a/src/df.c
+++ b/src/df.c
@@ -1708,21 +1708,25 @@ main (int argc, char **argv)
   stats = xnmalloc (argc - optind, sizeof *stats);
   for (int i = optind; i < argc; ++i)
 {
-  /* Prefer to open with O_NOCTTY and use fstat, but fall back
- on using "stat", in case the file is unreadable.  */
-  if (stat (argv[i], [i - optind]))
+#if O_PATH
+  int oflag = O_PATH;
+  bool skip_stat = true;
+#else
+  /* Fall back on stat in case the file is unreadable or is a
+ FIFO that would block.  */
+  int oflag = O_RDONLY | O_NOCTTY | O_NONBLOCK;
+  bool skip_stat = false;
+#endif
+  int fd = open (argv[i], oflag);
+  if ((fd < 0 || fstat (fd, [i - optind]) != 0)
+  && (skip_stat || stat (argv[i], [i - optind]) != 0))
 {
   error (0, errno, "%s", quotef (argv[i]));
   exit_status = EXIT_FAILURE;
   argv[i] = NULL;
 }
-  else if (! S_ISFIFO (stats[i - optind].st_mode))
-{
-  /* open() is needed to automount in some cases.  */
-  int fd = open (argv[i], O_RDONLY | O_NOCTTY);
-  if (0 <= fd)
-close (fd);
-}
+  if (0 <= fd)
+close (fd);
 }
 }
 
-- 
2.7.4