permissions getting changed on a spare drive's mount point [solved]

seth · 2018-01-27 20:58:34

seth wrote:

ME is required for sure

;-)

loqs · 2018-01-27 22:13:47

#!/usr/bin/python3

import os,subprocess

pid = os.getpid()

while pid > 1:
  cmdpath = "/proc/"+str(pid)+"/cmdline"
  with open(cmdpath) as f:
    line = f.readline()
    line = " ".join(line.split('\0'))
    subprocess.run(["logger","sudo trace",line])
  pidpath = "/proc/"+str(pid)+"/status"
  try:
    with open(pidpath) as f:
      for line in f:
        if line.startswith("PPid"):
          skip , ppid = line.split()
          pid = int(ppid)
          break
  except:
    pass
os.execvp("/usr/bin/sudo.bin",sys.argv)

In case it is needed to go any deeper
edit:
missed the call to the real sudo

Last edited by loqs (2018-01-27 22:44:29)

Trilby · 2018-01-27 22:19:18

Python could do, but there was a needless subshell (and useless cat) in the original script that was causing the trouble. `logger` will read from stdin:

logger < /proc/$$/cmdline
logger < /proc/$PPID/cmdline

You might also want to add a useful tag, e.g.:

logger -t sudo-debug < /proc/$$/cmdline

Or for the full process tree without python:

#!/bin/sh

pid=$$
while [ $pid -gt 0 ]; do
	logger -t sudo-debug < /proc/$pid/cmdline
	pid=$(sed -n 's/PPid:\t*//p' /proc/$pid/status)
done

exec /usr/bin/sudo.bin "$@"

Last edited by Trilby (2018-01-27 22:54:35)

graysky · 2018-01-27 22:44:03

Thanks Trilby. The problem with the while loop code is that sudo never completes the command... for example, `sudo su` returns to the shell. Perhaps append the exec line from the first script.

Last edited by graysky (2018-01-27 22:46:59)

loqs · 2018-01-27 22:50:04

Yes Trilby's command and my last one before revision both just parse the process tree.

Trilby · 2018-01-27 22:54:16

Yup, I editted to indicate the actual command needs to follow at the end. And also to rewrite it as I was horribly annoyed that I had to rely on a bashism ... until I realized it didn't matter if the sed command was in a subshell.

graysky · 2018-01-28 18:50:39

Thanks for the help so far... now that I have the logger script in place, of course, I am not seeing the error. I'll post back when I eventually do.

graysky · 2018-01-29 20:35:49

Just happened... guess I need the more advanced code:

Jan 29 15:33:40 radio sudo-debug[1545]: /bin/bash
Jan 29 15:33:40 radio sudo-debug[1546]: /bin/bash
Jan 29 15:33:40 radio sudo[1544]:  graysky : TTY=pts/1 ; PWD=/home/graysky ; USER=root ; COMMAND=/bin/chown -R graysky:users /incoming/
Jan 29 15:33:40 radio sudo.bin[1544]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 29 15:33:40 radio sudo.bin[1544]: pam_unix(sudo:session): session closed for user root

Last edited by graysky (2018-01-29 20:35:59)

R00KIE · 2018-01-29 21:13:52

Can you correlate the logged time to something you were doing around that time? You should have been asked for your password if you have set sudo to always ask for a password.

You could install psmisc and log the output of pstree for each sudo invocation, it might help to figure out from where sudo is being called. You might want to add a few options such as -a to get the full command line as this should help identify the offending sudo call.

graysky · 2018-01-29 21:51:26

@ROOKIE - Doing too many things at that time. I am using the 2nd script now which I probably should have done in the first place. Let's see...

loqs · 2018-01-29 22:28:18

From the output produced so far "TTY=pts/1" etc looks like it was triggered from something started in a terminal window.

graysky · 2018-01-31 00:26:23

Finally, something to go on:

Jan 30 17:27:51 radio sudo-debugmore[18133]: /bin/bash
Jan 30 17:27:51 radio sudo-debugmore[18135]: /bin/bash
Jan 30 17:27:51 radio sudo-debugmore[18137]: -zsh
Jan 30 17:27:51 radio sudo-debugmore[18139]: xfce4-terminal
Jan 30 17:27:51 radio sudo-debugmore[18141]: xfsettingsd
Jan 30 17:27:51 radio sudo-debugmore[18143]: /sbin/init
Jan 30 17:27:51 radio sudo[18132]:  graysky : TTY=pts/2 ; PWD=/home/graysky ; USER=root ; COMMAND=/bin/chown -R graysky:users /incoming/
Jan 30 17:27:51 radio sudo.bin[18132]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 30 17:27:51 radio sudo.bin[18132]: pam_unix(sudo:session): session closed for user root

... still no idea wtf is calling the chown.

Last edited by graysky (2018-01-31 00:27:20)

Trilby · 2018-01-31 00:41:42

Can we assume you did in fact have a xcfe4-terminal window open around that time?

Do you run zsh as your interactive shell? If so, it would seem a bash script was run from that shell that included the sudo chmod command. It should be in your zsh history.

B1omman · 2018-01-31 07:21:10

This is just gonna be some speculations since I don't use, nor have I previously used Xfce, but what about Thunar? Thunar interfaces some settings for auto-mounting and bookmarks etc (~/.gtk-bookmarks or something) which could be checked by xfsettingsd? Then if Xfce want's to have it's known location back, it would need to have the permissions changed as to not exceed the context it was spawned in (graysky:users)? I guess this bookmark/path/whatever it can be would be located in some .desktop-file or some xml-file with Thunar settings.

Sorry if this is completely insane and just waste of time, I don't use a DE myself since they are so magic...

R00KIE · 2018-01-31 12:52:17

The two bashes make me suspect it is a script (or a subshell?) called from another script which was executed with sudo. The xfsettingsd - xfce4-terminal is normal I believe, if you setup a keyboard shortcut to run xfce4-terminal it will show up like that.

Trilby · 2018-01-31 13:04:06

Rookie, the first bash is our replacement /usr/bin/sudo itself. So the actual chain is:

xfsettingsd -> xfcr4-terminal -> zsh -> bash -> /usr/bin/sudo

So from an interactive zsh session a script was run (with a bash or sh shebang) and that script included the sudo command.

As any command that was directly typed into an interactive terminal really should be obvious (unless someone else sits at the keyboard while Greysky is away for coffee) then I'd actually revise my previous suspicion that the command must be in the zsh history. I suspect it may actually shell script called from zsh's startup files. The diagnostics for this are relatively simple: 1) do the symptoms occur whenever a xcf4-terminal is launched, 2) are the symptoms prevented by using a clean zsh config and/or using a different shell.

Last edited by Trilby (2018-01-31 13:08:48)

B1omman · 2018-01-31 17:11:25

Trilby wrote:

xfsettingsd -> xfcr4-terminal -> zsh -> bash -> /usr/bin/sudo
So from an interactive zsh session a script was run (with a bash or sh shebang) and that script included the sudo command.

This is not far from what I tried to communicate, any settings daemon wouldn't need to be active until called upon, i.e. when launching the xfce4-terminal, then while/after setting up the shell it would read a change in the dev-tree and run the specified mount. However, some status script or prompt-blingbling would probably be the culprit...

Trilby · 2018-01-31 17:35:19

I doubt it B1omman, as the process change shows it was in a terminal in which zsh was running, and within that a bash shell ran the command with 'sudo'.

Processes spawned from a bound key may also have xfsettingsd as a parent, but not a gui terminal.

B1omman · 2018-01-31 18:09:51

Trilby wrote:

I don't believe in Magic.

I see...

Jokes aside, you are making sense and I share your doubt. Just hoping for some magic some time so I can feel okay with that I had an empty file named NULL and owned by root:root in my $HOME without being able to find out why for 3 years until I did a fresh install 3 weeks ago on a new disk. Nothing were creating it, but it appeared anyways at random times no matter how many times I deleted it. I gave up.

graysky · 2018-01-31 20:27:59

Mystery solved... I tracked it down to a call of chown in a backup script I manually call to sync files to my NAS for backup... I defined the sync target with a variable there which is why when I greped for 'incoming', the script did match, but I didn't put 2 and 2 together at the time <<head smack>>.

I knew this was going to end in pilot error; thanks to all for the discussion and the code snips.

Arch Linux

#26 2018-01-27 20:58:34

Re: permissions getting changed on a spare drive's mount point [solved]

#27 2018-01-27 22:13:47

Re: permissions getting changed on a spare drive's mount point [solved]

#28 2018-01-27 22:19:18

Re: permissions getting changed on a spare drive's mount point [solved]

#29 2018-01-27 22:44:03

Re: permissions getting changed on a spare drive's mount point [solved]

#30 2018-01-27 22:50:04

Re: permissions getting changed on a spare drive's mount point [solved]

#31 2018-01-27 22:54:16

Re: permissions getting changed on a spare drive's mount point [solved]

#32 2018-01-28 18:50:39

Re: permissions getting changed on a spare drive's mount point [solved]

#33 2018-01-29 20:35:49

Re: permissions getting changed on a spare drive's mount point [solved]

#34 2018-01-29 21:13:52

Re: permissions getting changed on a spare drive's mount point [solved]

#35 2018-01-29 21:51:26

Re: permissions getting changed on a spare drive's mount point [solved]

#36 2018-01-29 22:28:18

Re: permissions getting changed on a spare drive's mount point [solved]

#37 2018-01-31 00:26:23

Re: permissions getting changed on a spare drive's mount point [solved]

#38 2018-01-31 00:41:42

Re: permissions getting changed on a spare drive's mount point [solved]

#39 2018-01-31 07:21:10

Re: permissions getting changed on a spare drive's mount point [solved]

#40 2018-01-31 12:52:17

Re: permissions getting changed on a spare drive's mount point [solved]

#41 2018-01-31 13:04:06

Re: permissions getting changed on a spare drive's mount point [solved]

#42 2018-01-31 17:11:25

Re: permissions getting changed on a spare drive's mount point [solved]

#43 2018-01-31 17:35:19

Re: permissions getting changed on a spare drive's mount point [solved]

#44 2018-01-31 18:09:51

Re: permissions getting changed on a spare drive's mount point [solved]

#45 2018-01-31 20:27:59

Re: permissions getting changed on a spare drive's mount point [solved]

Board footer