Bug 14778 - 6_s1: /etc/profile.d/10tmpdir.* checking wrong file
Summary: 6_s1: /etc/profile.d/10tmpdir.* checking wrong file
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Colin Guthrie
QA Contact:
URL:
Whiteboard: MGA5TOO
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-11 12:46 CET by Bit Twister
Modified: 2016-07-06 22:30 CEST (History)
1 user (show)

See Also:
Source RPM: initscripts-9.55-13.mga5
CVE:
Status comment:


Attachments

Description Bit Twister 2014-12-11 12:46:44 CET
Description of problem:

/etc/profile.d]10tmpdir.* checking /etc/sysconfig/shell instead of
/etc/security/shell for SECURE_TMP

Version-Release number of selected component (if applicable):


How reproducible: always


Steps to Reproduce:
1. set SECURE_TMP=yes via mcc->Security->
Configure system security, permissions and audit->Security settings
->System security
2. cat /etc/security/shell to verify yes setting for SECURE_TMP
3. head -7 /etc/profile.d/10tmpdir.sh | tail -4
4. grep /etc/sysconfig/shell *
5. cat /etc/sysconfig/shell

Note: No such file or directory


A decision needs to be made to add msec test to /etc/profile.d/gconf.*
(GConf2-3.2.6-8.mga5.src.rpm) or place GCONF_TMPDIR in 10tmpdir.sh

I would also suggest maybe setting TEMP=$TMPDIR. IIRC some scripts used those but I can not provide any examples.



Reproducible: 

Steps to Reproduce:
David Walser 2014-12-20 01:26:07 CET

CC: (none) => mageia

Bit Twister 2015-04-28 00:30:52 CEST

Summary: 5a1: /etc/profile.d]10tmpdir.* checking wrong file => 5a1: /etc/profile.d/10tmpdir.* checking wrong file
Source RPM: initscripts-9.55-10.mga5 => initscripts-9.55-13.mga5

Comment 1 Mageia Robot 2015-04-28 10:45:26 CEST
commit 8296e4b8b597ccd3f197c9fa489003d97951b6e9
Author: Colin Guthrie <colin@...>
Date:   Tue Apr 28 09:44:24 2015 +0100

    Check correct msec config file for SECURE_TMP config.
    
    Note: I think this is bogus. It doesn't deal properly with homedirs
    on NFS with SECURE_TMP set as many programs require filesystem
    behaviour that NFS cannot honour. If anything, the tmp folder
    should be mounted as tmpfs.
    
    Ultimately however this is what XDG_RUNTIME_DIR is meant to
    do and programs should generally move away from it.
    
    I'd suggest even that TMP and TMPDIR point to /run/user/603/tmp
    if you want a really secure TMPDIR system.
    
    Or at least something along those lines.
    
    mga#14778
---
 Commit Link:
   http://gitweb.mageia.org/software/forks/initscripts/commit/?id=8296e4b8b597ccd3f197c9fa489003d97951b6e9
Comment 2 Bit Twister 2015-04-28 11:48:57 CEST
(In reply to Mageia Robot from comment #1)
> commit 8296e4b8b597ccd3f197c9fa489003d97951b6e9
> Author: Colin Guthrie <colin@...>
> Date:   Tue Apr 28 09:44:24 2015 +0100
> 
>     Check correct msec config file for SECURE_TMP config.
>     
>     Note: I think this is bogus. 

I am going to assume the "this is bogus" applies to the actual temp security and not the bug report.


>  It doesn't deal properly with homedirs
>     on NFS with SECURE_TMP set as many programs require filesystem
>     behaviour that NFS cannot honour. If anything, the tmp folder
>     should be mounted as tmpfs.

Yuck, I hate to see ram wasted on files in ~/tmp

>     Ultimately however this is what XDG_RUNTIME_DIR is meant to
>     do and programs should generally move away from it.
>     
>     I'd suggest even that TMP and TMPDIR point to /run/user/603/tmp
>     if you want a really secure TMPDIR system.

There are a couple of problems with that. 
I think tmp secure is chmod 700 ~/tmp is good enough to meet original requirements. Personally I think secure should be chmod 700 /home/$USER

1. No clue about GNOME but KDE start up time would noticeably increase if it can not find the directories/files found in KDEVARTMP or KDETMP location.
Current out-of-the-box default location is /var/tmp.

2. That /run/user/nnnn is causing directory/file not found noise in the journal for my user cron jobs or for all my sudo su - $USER interactive stuff. My solution is a hourly root job to create the /run/user stuff before the users cron job runs.

current kludge to suppress noise snippet:
        XDG_RUNTIME_DIR=/run/user/$_uid
        for _d in dbus dconf gvfs ksocket-$-id pulse systemd ; do
          mkdir -p $XDG_RUNTIME_DIR/$_d
          chmod 700 $XDG_RUNTIME_DIR/$_d
        done
        touch $XDG_RUNTIME_DIR/systemd/notify
        chmod 700 $XDG_RUNTIME_DIR
        chown -R $_uid:$_gid $XDG_RUNTIME_DIR
Comment 3 Samuel Verschelde 2015-06-06 02:39:29 CEST
In the end, is the bug fixed or not? (Note to Bit Twister: you were answering to a commit message, not to a comment)
Samuel Verschelde 2015-06-06 02:39:36 CEST

Keywords: (none) => NEEDINFO

Comment 4 Bit Twister 2015-06-06 03:21:57 CEST
(In reply to Samuel VERSCHELDE from comment #3)
> In the end, is the bug fixed or not? 

I do not know for sure because I patched my install before I opened a bug.

I ran through my open bugs and resolved all that I could prove were fixed.

Since I always do clean installs, I plan on testing my 48 open bugs again when the next Mageia-5-x86_64-DVD.iso comes out.

I'll leave it up to you to decide to remove the NEEDINFO or not.
Comment 5 Bit Twister 2015-07-01 11:42:08 CEST
(In reply to Samuel VERSCHELDE from comment #3)
> In the end, is the bug fixed or not? 

The code has not been changed
from   /etc/sysconfig/shell
to     /etc/security/shell

The bug is still valid on Release 5.

Keywords: NEEDINFO => (none)

Samuel Verschelde 2015-07-01 12:30:24 CEST

Assignee: bugsquad => mageia
Summary: 5a1: /etc/profile.d/10tmpdir.* checking wrong file => /etc/profile.d/10tmpdir.* checking wrong file
Whiteboard: (none) => MGA5TOO

Bit Twister 2016-07-06 22:25:03 CEST

Summary: /etc/profile.d/10tmpdir.* checking wrong file => 6_s1: /etc/profile.d/10tmpdir.* checking wrong file

Comment 6 Bit Twister 2016-07-06 22:30:46 CEST
 Problem no longer occurs.

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.