View previous topic :: View next topic |
Author |
Message |
soehest n00b
Joined: 30 Aug 2007 Posts: 15
|
Posted: Mon Aug 06, 2012 7:52 pm Post subject: Wierd permissions on /var/run/lock (dev-libs/lockdev) |
|
|
i
I am trying to figure out why the permissions on /var/run/lock are 755 owner root and group uucp
Code: | test run # ls -ld /var/run/lock
drwxr-xr-x 2 root uucp 40 Aug 6 23:29 /var/run/lock
|
I am using the library dev-libs/libcec which depends on dev-libs/lockdev, and with those permission it is not enough to add the the user to group uucp to allow writing to /var/lock, as group uucp does not have write permissions on /var/run/lock. My current fix at the moment is to create /etc/conf.d/local with the following content:
Code: | chmod 775 /var/lock |
Ubuntu have different permissions (777)
Code: | soehest@ubuntu:/var/run$ ls -ld /var/run/lock
drwxrwxrwt 4 root root 80 Aug 6 12:37 /var/run/lock |
So the big question. Which is more correct ubuntu or gentoo permissions? and there must be a better fix than the one i am currently using? |
|
Back to top |
|
|
mbjr Guru
Joined: 17 Jan 2004 Posts: 531 Location: Budapest/Hungary
|
Posted: Tue Aug 07, 2012 8:24 am Post subject: |
|
|
Without getting into much details, 777 is simply over-allowing.
I would go with 775 (as I'd expect write permissions to be given to the group (uucp)), if I were running into an issue. Not before. _________________ mb |
|
Back to top |
|
|
soehest n00b
Joined: 30 Aug 2007 Posts: 15
|
Posted: Wed Aug 15, 2012 9:43 am Post subject: |
|
|
mbjr wrote: | Without getting into much details, 777 is simply over-allowing.
I would go with 775 (as I'd expect write permissions to be given to the group (uucp)), if I were running into an issue. Not before. |
I agree with that. But why isn't that default on the install?. I have been unable to locate which program that changes the permissions at boot. They are changed back every time hence the local fix. There much surely be a better (correct) fix than to chmod using /etc/conf.d/local?
Best regards |
|
Back to top |
|
|
AlbertVeli n00b
Joined: 15 Aug 2012 Posts: 7
|
Posted: Wed Aug 15, 2012 12:36 pm Post subject: |
|
|
I have the same problem. Kermit won't run because it fails to create a lockfile in /run/lock/. That dir has mode 755, and the group is uucp (which I belong to). If I chmod 775 /run/lock then it works.
But some script seems to clean the whole /run on shutdown or bootup and when /run/lock is created (bootmisc init script?) it is created with perm 755. |
|
Back to top |
|
|
gemi n00b
Joined: 10 Oct 2012 Posts: 31
|
Posted: Thu Oct 18, 2012 12:38 am Post subject: |
|
|
same problem for me.
/run/lock permissions get changed every reboot back to no writes for group uucp
that way kermit does not work
how to stop that?
Any news/ideas on this one? |
|
Back to top |
|
|
ebichu Apprentice
Joined: 03 Jul 2002 Posts: 231 Location: Manchester, England
|
Posted: Wed Oct 23, 2013 12:47 pm Post subject: |
|
|
Sorry to dig up an old thread. It seems "/run/lock" (which "/var/lock" should be symlinked to) now gets created with owner:group "root:uucp" and permissions "0775", which I guess solves the original problem. However, recent versions of udev (at least the systemd variant) set the group owner of serial ports to "dialout", which means that users now wishing to use the serial ports have to be members of both the "uucp" and "dialout" groups!
I wonder why Debian and Ubuntu use permissions "1777" for the lock directory? _________________ Ebichu wa chiizu ga daisuki dechu! |
|
Back to top |
|
|
|