default umask of 0077 too restrictive for scripts

Bug #255856 reported by Andreas Hasenack
4
Affects Status Importance Assigned to Milestone
Landscape Client
Fix Released
Medium
Kevin McDermott
Landscape Server
Fix Released
Medium
Kevin McDermott

Bug Description

For some reason (still investigating), smart's config file was mode 0600 in five installations:
drwxr-xr-x 4 root root 4096 2008-08-07 20:19 .
drwxr-xr-x 25 root root 4096 2008-08-06 20:05 ..
-rw-r--r-- 1 root root 6056528 2008-08-07 20:17 cache
drwxr-xr-x 2 root root 12288 2008-08-07 20:19 channels
-rw------- 1 root root 1722 2008-08-07 20:19 config
-rw-r--r-- 1 root root 1914 2008-08-07 20:17 config.old
drwxr-xr-x 2 root root 4096 2008-08-06 21:06 packages

This prevents regular users from using it even for just read access.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

This happened because a "smart update" command was sent to the machine via Landscape's script execution plugin. That plugin sets the umask to 0077 before running the script.

Smart moves the config file to .old and creates a new one, so this operation is affected by the current umask. That's how the config file got mode 0600 while the previous one was 0644.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

After a brief discussion on IRC, we think it would be best to just set the umask to the default value in ubuntu before running scripts: 0022.

Changed in landscape-client:
importance: Undecided → Medium
Changed in landscape:
importance: Undecided → Medium
milestone: none → thames-pre-6
status: New → Confirmed
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Moved to thames-pre-7.

Changed in landscape:
milestone: thames-pre-6 → thames-pre-7
Revision history for this message
Kevin McDermott (bigkevmcd) wrote :

I've added a test and fix which sets the umask before executing the script, and then restores it when we finish removing the script.

Changed in landscape-client:
assignee: nobody → kevin-mcdermott
status: New → In Progress
Changed in landscape:
assignee: nobody → kevin-mcdermott
status: Confirmed → In Progress
Revision history for this message
Thomas Herve (therve) wrote :

OK cool. The only problem is that the test doesn't check the umask *during* the script, only that os.umask is called. Instead of 'echo hi', you could call umask and check the result?

Otherwise, +1.

Revision history for this message
Jamu Kakar (jkakar) wrote :

[1]

+ old_umask = os.umask(0022)
         env = {}
         attachment_dir = ""
         if attachments:
@@ -183,9 +184,10 @@
         if time_limit is not None:
             pp.schedule_cancel(time_limit)
         result = pp.result_deferred
- return result.addBoth(self._remove_script, filename, attachment_dir)
+ return result.addBoth(self._remove_script, filename, attachment_dir,
+ old_umask)

I think this whole block of code should be protected in a try/except like:

        old_umask = os.umask(0022)
        try:
            ...
            return result.addBoth(...)
        except:
            os.umask(old_umask)
            raise

Short and sweet, the best kind of branch. +1!

Changed in landscape-client:
status: In Progress → Fix Committed
Changed in landscape:
status: In Progress → Fix Committed
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

umask is fine now!

qa + 1

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

This was released into production.

Changed in landscape-client:
status: Fix Committed → Fix Released
Changed in landscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.