GNU bug report logs - #45182
mktemp not created other permissions

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45182 in the body.
You can then email your comments to 45182 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Vasanth M.Vasanth" <vasanth3g <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: mktemp not created other permissions
Date: Fri, 11 Dec 2020 19:17:16 +0530

[Message part 1 (text/plain, inline)]

Hi Team,

When I create a temp file from root users using mktemp command, then it is
not able to access other users. If the same do in other users then the
group and user came respectively.

Is this default behaviour or any flags available?



Thanks,
Vasanth

[Message part 2 (text/html, inline)]

Message #8 received at 45182 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: "Vasanth M.Vasanth" <vasanth3g <at> gmail.com>
Cc: 45182 <at> debbugs.gnu.org
Subject: Re: bug#45182: mktemp not created other permissions
Date: Mon, 8 Mar 2021 22:07:34 -0700

close 45182
tag 45182 + notabug
thanks

Vasanth M.Vasanth wrote:
> When I create a temp file from root users using mktemp command, then it is
> not able to access other users. If the same do in other users then the
> group and user came respectively.

I see no difference in behavior of GNU Coreutils mktemp when used as a
root user or as a non-root user.

    # mktemp
    /tmp/tmp.7smatw2ZW5

    # ls -ld /tmp/tmp.7smatw2ZW5
    -rw------- 1 root root 0 Mar  8 21:56 /tmp/tmp.7smatw2ZW5

    $ mktemp
    /tmp/tmp.nnyNVef0wB

    $ ls -ld /tmp/tmp.nnyNVef0wB
    -rw------- 1 rwp rwp 0 Mar  8 21:54 /tmp/tmp.nnyNVef0wB

Therefore I am at a loss to understand the report that there are differences.

Also the purpose and intent of mktemp is to create files that are
accessible by the creating user only and not by other users and not by
other groups.  This is documented in the manual as this following.

       When creating a file, the resulting file has read and write
    permissions for the current user, but no permissions for the group or
    others; these permissions are reduced if the current umask is more
    restrictive.

Therefore if I read your question about permissions correctly, yes
this is documented and intended behavior.

> Is this default behaviour or any flags available?

No.  The files created will always be such that the current user has
read and write permissions but no permissions for group or others.

Regarding users and groups however.  The default permission for
non-root, non-priviledged users in most modern operating systems is
that non-priviledged users cannot chown files.  That is a kernel level
restriction and not a restriction of GNU Coreutils.  If the OS allows
it then chown will do it.  If the OS does not allow it then it is the
kernel that is restricting it.  The root superuser however always has
full permission for chown actions.

If you desire less strict permissions then this may easily be
accomplished by chmod'ing the file afterward.  Such as this example.

    tmpfile=$(mktemp) || exit 1
    chmod g+w "$tmpfile"

And for a root user setting up a file or directory for another process
then the root user may chown and chgrp the file too.

    tmpfile=$(mktemp) || exit 1
    chmod g+w "$tmpfile"
    chgrp somesharedgroup "$tmpfile"

This ordering is important.  Because a file that is created securely
may be relaxed.  But a file created with relaxed permissions may never
safely made securely restricted.  Therefore the files must be strict
from the start and only relaxed if that is the desire.

Thank you for your bug report.  However as the command is operating as
intended and documented I am going to close this bug ticket.  But
please if there is additional information feel free to add it to the
ticket.  It will be read and if there is a reason then the ticket will
be opened again.

Bob

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.