On 01/12/2016 10:38, Douglas R. Reno wrote:


On Thu, Dec 1, 2016 at 3:33 AM, Pierre Labastie <pierre.labas...@neuf.fr <mailto:pierre.labas...@neuf.fr>> wrote:

    On 01/12/2016 07:56, Douglas R. Reno wrote:

        Pierre Labastie wrote:

            On 01/12/2016 04:38, Douglas R. Reno wrote:

                Hello,

                Upon trying to run the newaliases command in the
                Configuration Information page, I'll get the following
                error:

                newaliases: cannot open /etc/mail/aliases: Group
                writable file

                For context, these are the commands that I ran
                (similar to the book):

                renodr [ /sources ]$ su
                Password:
                root [ /sources ]# echo $(hostname) >
                /etc/mail/local-host-names
                root [ /sources ]# cat > /etc/mail/aliases << "EOF"
                > postmaster: root
                > MAILER-DAEMON: root
                >
                > EOF
                root [ /sources ]# newaliases
                newaliases: cannot open /etc/mail/aliases: Group
                writable file
                root [ /sources ]#

                In order to fix this, I had to run something similar to:

                root [ /sources ]# chmod -v 644 /etc/mail/aliases
                mode of '/etc/mail/aliases' changed from 0664
                (rw-rw-r--) to 0644 (rw-r--r--)
                root [ /sources ]# newaliases
                /etc/mail/aliases: 2 aliases, longest 4 bytes, 31
                bytes total

                I propose adding the "chmod -v 644 /etc/mail/aliases"
                command to the book.

                I'd like to ask for comments / suggestions before I
                put it in there myself.

            I guess it is an "umask" problem. Normally, if your bash
            startup files are set as in the book, umask should be 022
            when you are root, and no additional instruction should be
            necessary. OTOH, maybe su does not run the bash startup
            files...

            Regards
            Pierre

        As far as I can see after tracing it for a little bit, I can't
        find a line in /root/.bashrc, /etc/profile, /etc/bashrc, or
        /root/.bash_profile that accomplishes that. However, we do
        execute it in /etc/profile.d/umask.sh.


        When I am "su"ed to root, my umask is 0022. If I use my normal
        user, my umask is 0002.

        root [ ~ ]# umask
        0022

        renodr [ /sources ]$ umask
        0002

        I just verified that all of my bash startup files are
        identical to the ones in the book.

    If I use "su", my umask as root is the same as that of pierre (0002)
    If I use "su -", umask is correctly set to 0022 (but of course the
    working directory is  changed to /root)
    what I use in my scripts is
    sudo -E sh << ROOT_EOF
    <root commands>
    ROOT_EOF
    If I do that, umask is 0022, and CWD is not changed. I cannot
    understand what makes the difference with su (I do not use this
    command, that's why...)

    Pierre


Hmm...

I can try what you are doing for sudo. In my case, just running "sudo cat... << EOF" gives me a permission denied error (if I recall correctly, I haven't tried that in a long time).

Here's an explanation as to why "su - " and "su" do different things.

"su - <user>" forces a new login session to be spawned I think, which is why it resets the working directory to the new user's home directory. If one just uses "su" or "su <user>", I think that it tells it to change to that user but preserve the current environment.
Actually umask is not really in the "environment".The difference in behavior comes from the difference in default implementations of sudo and su.
From "man sudoers", about the variable "umask":
------
Umask to use when running the command.  Negate this
option or set it to 0777 to preserve the user's umask.
The actual umask that is used will be the union of the
user's umask and the value of the umask option, which
defaults to 0022.  This guarantees that sudo never low‐
ers the umask when running a command.  Note: on systems
that use PAM, the default PAM configuration may specify
its own umask which will override the value set in
sudoers.
------

"man su" does not have much to say about umask.
"man login.defs" has more, but I guess systemd users have PAM, which overrides all that:
------
       UMASK (number)
           The file mode creation mask is initialized to this value. If not
           specified, the mask will be initialized to 022.

           useradd and newusers use this mask to set the mode of the home
           directory they create

           It is also used by pam_umask as the default umask value.
------
It is explicitly said at the end of that man page that su does not use UMASK. So I understand that, with su, you get whatever umask is set by the shell. Since "su" (not "su -") opens a non login shell, only .bashrc is run, and umask is not modified...

One thing could be to try using the "pam_umask" module in /etc/pam.d/su:
add a line at the right place (to be determined):
----
session optional pam_umask.so usergroups umask=0022
----
That would set umask=022 for root, but umask=002 for any user whose primary group has the same name as the user (default for a user created with useradd).

Another possibility, as suggested by akh, eliminating the need to set umask for su, sudo, etc:
replace all our "cat > /path/to/something << EOF" in the book by:
----
(as user)
cat >something.tmp << EOF
blah
EOF
(as root)
install -m xxx something.tmp /path/to/something
----
Pierre

--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to