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

graysky · 2018-01-27 00:47:48

I have a 2nd drive mounted to /incoming. As the title states, something is changing the group and permissions to it. I'd like to understand what is doing it and stop it.

How I made the mount:

mkdir /incoming
chown graysky:work /incoming
chmod 770 /incoming

# I added this line to my /etc/fstab
  LABEL=incoming /incoming    ext4 defaults,relatime 0 2

mount /incoming
chown graysky:work /incoming
chmod 770 /incoming

So when I run an `ls -l /` I see the expected result:

...
drwxrwx---   8 graysky work  4096 Jan 19 14:57 incoming
...

But after a few hours of uptime, this happens:

ls -l /
...
drwxr-xr-x   8 graysky users  4096 Jan 19 14:57 incoming
...

Last edited by graysky (2018-01-31 20:28:22)

Trilby · 2018-01-27 00:50:34

`stat` output would be far more helpful that `ls`. Specifically, I'd want to know whether the problem is the group ownership of the directory actually changing, or are the group -> id mappings changing?

graysky · 2018-01-27 00:57:00

@Trilby - If I boot to the live CD, the owner/group is consistent. If I wait until it changes, then reboot to the live CD, the owner/group is consistent in that it has been changed. Currently, I manually changed it back to my liking and stat output is below. I should also note that the permissions on sub directories under /incoming get modified as well. I want them to be 700 but they get mysteriously changed to 755 as well.

% stat /incoming
  File: /incoming
  Size: 4096        Blocks: 8          IO Block: 4096   directory
Device: 812h/2066d  Inode: 2           Links: 9
Access: (0770/drwxrwx---)  Uid: ( 1000/ graysky)   Gid: (  555/  work)
Access: 2018-01-26 19:49:56.986844969 -0500
Modify: 2018-01-26 19:49:56.983511486 -0500
Change: 2018-01-26 19:49:56.983511486 -0500
 Birth: -

seth · 2018-01-27 10:25:37

If I boot to the live CD

?

https://www.tomaz.me/2014/01/08/detecti … trick.html
There's no "easy" way to monitor this, but if the culprit is running long enough, you might be lucky in wiring inotifywait to lsof.

Since the dir belongs to "your" user, I'd initially blame baloo/tracker/otherindexingshit, but a simple overzealous chmod -R in some cronjob might be the culprit just as well.

Trilby · 2018-01-27 11:53:02

seth wrote:

If I boot to the live CD
?

My thoughts exactly. I have no idea why yet another variable was added to the process. I was hoping to eliminate one of two possible varieties of cause of the problem, instead new ones were added.

graysky · 2018-01-27 11:53:24

Just happened again... inspecting journalctl it seems that something is running as my user doing this:

Jan 27 06:40:45 radio sudo[16429]:  graysky : TTY=pts/3 ; PWD=/home/graysky ; USER=root ; COMMAND=/bin/chown -R graysky:users /incoming/
Jan 27 06:40:45 radio sudo[16429]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 27 06:40:45 radio sudo[16429]: pam_unix(sudo:session): session closed for user root

Trilby · 2018-01-27 11:53:53

seth wrote:

Since the dir belongs to "your" user, I'd initially blame baloo/tracker/otherindexingshit

Like profile/anything sync daemon?

graysky · 2018-01-27 11:58:40

@Trilby: Not either of them... I am only using psd and that is specific for $HOME/subdirs using overlayfs. I don't see that whatever triggered the /bin/chown as being executed from cron. If I grep for 'incoming' in my ~/bin I have no hits and in /root/bin.

Last edited by graysky (2018-01-27 12:08:14)

R00KIE · 2018-01-27 13:02:50

Do you happen to have something configured in your shell or root's shell to run _after_ you run commands with sudo? Although I would be more inclined to say the problem comes from your user's side.

I think it is possible to change the configuration in the sudoers file (or with an extra file in sudoers.d) to make sudo forget the password right after use. From the looks of it the chown is being run directly with sudo so making sudo always ask for a password might help you catch the culprit if it is some script you are running.

seth · 2018-01-27 13:52:18

Checked crontab for time matches?
Maybe also some udev rule?
Replace /usr/bin/sudo with a script that call moved /usr/bin/sudo.bin and logs command and parenting process? Maybe sends a notification, waits for confirmance and allows you to inspect running processes?

graysky · 2018-01-27 15:13:24

@ROOKIE - I do not... `grep chown` ~/.zshrc gives nothing. Same for `grep chown /root/.zshrc` I changed sudo's behavior to timeout as you suggested. I think that will prevent this but it won't help me figure out what is doing it.

@seth - Yes, the entry I pasted into the thread above has no cron/crond entries near it. It is isolated by 5 min of any entries at all. As well, root's cron tab is empty; my crontab only has an entry for backintime's nightly run which doesn't even touch the mount point.

I like your idea to replace sudo with a script that records stuff to a log... journalctl already records the pid... how would one record the location of the invoking command?

seth · 2018-01-27 15:38:31

/proc/$PID/cmdline

R00KIE · 2018-01-27 17:00:30

I was thinking something aggressive like setting the timeout to zero to always ask the password in every sudo invocation, that way you can do two things, catch sudo invocations you are not expecting and after granting sudo privileges check the permissions on the directory.

I was remembering that you don't want to be a member of the sudoers group, very recently there was someone here on the forums fighting to have sudo ask for a password and it turned out that by being a member of the sudoers group no password was being asked. Being a member of the wheel group should do the trick.

graysky · 2018-01-27 17:22:33

Via `visudo` I changed the wheel group behavior to always require a password. I'm not sure how this will be diagnostic without modifying /usr/bin/sudo as a script to log attempts though.

R00KIE · 2018-01-27 17:48:26

You probably want both approaches, always asking for a password and logging. If the problem is not obvious you have to bring the big guns

c00ter · 2018-01-27 19:01:14

graysky wrote:

Via `visudo` I changed the wheel group behavior to always require a password. I'm not sure how this will be diagnostic without modifying /usr/bin/sudo as a script to log attempts though.

In an earlier post you mentioned PSD and the Overlay. Considering PSD's overlay requires altering sudoers, I feel that somehow that and your problems are related. As a member of "wheel" I do not have your issues. I wish I had hard-data to back that up but...

graysky · 2018-01-27 19:18:14

c00ter wrote:

In an earlier post you mentioned PSD and the Overlay. Considering PSD's overlay requires altering sudoers, I feel that somehow that and your problems are related. As a member of "wheel" I do not have your issues. I wish I had hard-data to back that up but...

The way psd does it is via `graysky ALL=(ALL) NOPASSWD: /usr/bin/psd-overlay-helper` but there is no call to chown in that script.

graysky · 2018-01-27 19:48:42

I'm failing to come up with a script for logging calls to /usr/bin/sudo. The goal is to discover what is calling the chmod.

loqs · 2018-01-27 19:50:59

Possibly substitute /usr/bin/sudo with the following and move sudo to sudo.bin

#!/usr/bin/bash
logger `cat "/proc/self/cmdline"` #this will probably be sudo
logger `cat "/proc/$PPID/cmdline"` #this should be the caller
exec /usr/bin/sudo.bin "$@"

Edit:
Fixed missing see post #28 for a better script by Trilby

Last edited by loqs (2018-01-27 23:05:02)

graysky · 2018-01-27 20:33:37

@loqs - I gave that a shot, but it's throwing errors:

% sudo echo test
/bin/sudo: line 2: warning: command substitution: ignored null byte in input
/bin/sudo: line 3: warning: command substitution: ignored null byte in input
logger: invalid option -- 'z'
Try 'logger --help' for more information.
test

Last edited by graysky (2018-01-27 20:33:45)

loqs · 2018-01-27 20:39:09

The null byte one I was expecting option z must be coming from the string that was meant to be sent to logger. Try changing logger to `logger -- ` so it will ignore
Edit:
no backticks just add --

Last edited by loqs (2018-01-27 20:39:37)

seth · 2018-01-27 20:40:51

#!/bin/bash
ME=$$
DAD=$PPID
logger `cat "/proc/$ME/cmdline"` # this will probably be sudo
logger `cat "/proc/$DAD/cmdline"` #this should be the caller
exec /usr/bin/sudo.bin "$@"

ME is required for sure, DAD might be depending on the subshell acts (I don't think it is, but better safe than ... dad ;-) and the shebang was invalid.

graysky · 2018-01-27 20:45:09

@seth - I caught the shebang. Your code seems to give the desired effect albeit it with some warnings.

% sudo echo "good idea"
/bin/sudo: line 4: warning: command substitution: ignored null byte in input
/bin/sudo: line 5: warning: command substitution: ignored null byte in input
logger: invalid option -- 'z'
Try 'logger --help' for more information.
good idea

...

% journalctl
...
Jan 27 15:44:16 radio graysky[23782]: /bin/bash/bin/sudoechogood idea
Jan 27 15:44:16 radio sudo[23780]:  graysky : TTY=pts/0 ; PWD=/home/graysky ; USER=root ; COMMAND=/bin/echo good idea
Jan 27 15:44:16 radio sudo.bin[23780]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 27 15:44:16 radio sudo.bin[23780]: pam_unix(sudo:session): session closed for user root

seth · 2018-01-27 20:48:42

See loqs' comment for the logger syntax. And then let's hope.
A problem I would forsee here is that the sudo call itself is likely wrapped inside a script, so the cmdline of the parenting process will be /bin/bash ... you'd then have to walk up the process tree.

loqs · 2018-01-27 20:51:09

Hmm might need one more level getting this as the output here

cat/proc/self/cmdline
bash

Arch Linux

#1 2018-01-27 00:47:48

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

#2 2018-01-27 00:50:34

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

#3 2018-01-27 00:57:00

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

#4 2018-01-27 10:25:37

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

#5 2018-01-27 11:53:02

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

#6 2018-01-27 11:53:24

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

#7 2018-01-27 11:53:53

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

#8 2018-01-27 11:58:40

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

#9 2018-01-27 13:02:50

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

#10 2018-01-27 13:52:18

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

#11 2018-01-27 15:13:24

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

#12 2018-01-27 15:38:31

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

#13 2018-01-27 17:00:30

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

#14 2018-01-27 17:22:33

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

#15 2018-01-27 17:48:26

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

#16 2018-01-27 19:01:14

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

#17 2018-01-27 19:18:14

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

#18 2018-01-27 19:48:42

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

#19 2018-01-27 19:50:59

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

#20 2018-01-27 20:33:37

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

#21 2018-01-27 20:39:09

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

#22 2018-01-27 20:40:51

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

#23 2018-01-27 20:45:09

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

#24 2018-01-27 20:48:42

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

#25 2018-01-27 20:51:09

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

Board footer