1

I have been testing a udev rule when plugging usb.

I guess my problem might have something to do with this post: Cannot run script using udev rules

I have the following udev rule, which successfully triggers and runs the script:

ACTION=="add", SUBSYSTEM=="block", DRIVERS=="usb", ATTRS{idProduct}=="3244", ATTRS{idVendor}=="hghh", ATTR{size}=="7685844", RUN="/home/user/trigger"

The script itself:

#!/bin/bash
date >> /home/user/udev_test.log
date >> /tmp/udev_test.log

When triggered manually the script writes to both files (with user permissions). When triggered by udev, only file in user directory gets a date.

Also I can write to /tmp/udev_test.log directly via something like echo "blah" >> /tmp/udev_test.log

I tried with 644, 664 and 777 on /tmp/udev_test.log file, but nothing worked.

Why can I write there manually with user permissions, but with udev it does not work even if permissions are set to 777?

laksdjfg
  • 11
  • 1
    It is possible, that when triggered by udev, the user is not the one you expect. Is the user in the script literally user or your first name or something else or $USER? Are there permissions when triggered by udev to write into /home/user? – sudodus Jul 31 '22 at 11:14
  • it's not literally user, but another login name. Are there permissions when triggered by udev to write into /home/user? - do you mean what permissions the file has that was modified by udev in user directory? – laksdjfg Aug 01 '22 at 08:05
  • 1
    I mean: Is 'udev' allowed to write into /home/user ? Or maybe some other user ID, that initiates and tries to perform the write operation, is that user ID allowed to write there? You can check not only the permissions on the target file, but also on the directory /home/user. – sudodus Aug 01 '22 at 08:40
  • @sudodus note that as I understand it, date >> /home/user/udev_test.log worked fine, the part which failed to produce a visible result was date >> /tmp/udev_test.log. This feels like PrivateTmp but I’m not sure that actually applies to udev rules. – Stephen Kitt Aug 01 '22 at 08:43
  • @StephenKitt, Sorry, in that case I misunderstood. Let the original poster make that issue clear. If I understand correctly, the directory /tmp should have enough permissions for every possible user ID to write, so in that case only the permissions of the file are relevant. – sudodus Aug 01 '22 at 08:45
  • 2
    @sudodus “When triggered by udev, only file in user directory gets a date.” seems clear enough to me. And yes, /tmp should be writable by anything, but systemd knows how to provide a private tmp, which may be what’s happening here — the rule might write to a file in a private tmp, not the “real” /tmp. – Stephen Kitt Aug 01 '22 at 08:53
  • 1
    @StephenKitt How to check/know whether this "shadow tmp" exist or where to find it? (sounds like a unix quest :D) – laksdjfg Aug 01 '22 at 10:54
  • This question is crying out for more information, investigation and debugging.  Does the /tmp/udev_test.log file already exist when you do this?  I guess that it does, from the statement that you tried various modes.  What happens if it doesn’t exist when you run the test (or, equivalently, if the script tries to create a new, different file, e.g.,  /tmp/udev_test_$$.log)?  Modify the script to do id, sh -c 'date >> /tmp/udev_test.log' 2>&1 and ls -lai /tmp with output to the /home directory. Etc. – G-Man Says 'Reinstate Monica' Aug 16 '22 at 05:04

1 Answers1

1

The /tmp directory has a special mode called sticky bit mode.  Only the user that is the owner of the file can write to this file.  According to my tutorial:

3.4.2.5. Special modes

For the system admin to not be bothered solving permission problems all the time, special access rights can be given to entire directories, or to separate programs. There are three special modes:

Sticky bit mode: After execution of a job, the command is kept in the system memory. Originally this was a feature used a lot to save memory: big jobs are loaded into memory only once. But these days memory is inexpensive and there are better techniques to manage it, so it is not used anymore for its optimizing capabilities on single files. When applied to an entire directory, however, the sticky bit has a different meaning. In that case, a user can only change files in this directory when she is the user owner of the file or when the file has appropriate permissions. This feature is used on directories like /var/tmp, that have to be accessible for everyone, but where it is not appropriate for users to change or delete each other's data. The sticky bit is indicated by a t at the end of the file permission field:

mark:~> ls -ld /var/tmp 
drwxrwxrwt 19 root root 8192 Jan 16 10:37 /var/tmp/

        ︙

Does this help?

G-Man Says 'Reinstate Monica'
  • 22,870
Frans van Spiegel
  • 11