Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Basically, I want to get socket and pipe owners starting from a PID located in the /proc/PID/fd/ directory using the "stat" command:
lrwx------ 1 root root 64 dic 23 17:52 0 -> socket:[9790]
l-wx------ 1 root root 64 dic 23 17:52 1 -> /var/log/messages
l-wx------ 1 root root 64 dic 23 17:52 2 -> /var/log/secure
lr-x------ 1 root root 64 dic 23 17:52 3 -> /proc/kmsg
l-wx------ 1 root root 64 dic 23 17:52 4 -> /var/log/maillog
l-wx------ 1 root root 64 dic 23 17:52 5 -> /var/log/cron
How could I use "stat" to get each socket owner when I just have the socket name (socket:[9790]) instead of its symbolic reference (0,1,2...)?
Thanks for your answer!
For this lsof is much better.
You can use lsof -i -a -p $PID.
There is a similar question on the unix hub on the StackExchange.
https://unix.stackexchange.com/questions/235979/how-do-i-find-out-more-about-socket-files-in-proc-fd
I think that should solve your problem.
I do not think that you can do this with one simple stat instruction. Instead you could try to utilize find in order to search for symbolic links an then print them formatted. You can then, e.g., pipe the result to grep and cut to filter for the information you need:
find /proc/PID/fd/ -type l -printf '%u %l\n' 2>/dev/null|grep "socket:[9790]"|cut -d' ' -f1
You can use find's options (-mindepth, -maxdepth) in order to determine how deep it shall descend into subfolders for its search. If you want the owner's UID instead of the username then use %U instead of %u in -printf.
Related
I bumped into the fact that MacOS GNU bash5.1.16 "ls" command doesn't differentiate between lower and upper case in the files names ( weird, I know)
e.g.
[17:39:28:~/Work/cloud-formation/output/templates$] ls -l Man*
-rw-r--r-- 1 geoku staff 71244 31 Jan 17:23 ManagementProd.json
-rw-r--r-- 1 geoku staff 67569 31 Jan 17:23 ManagementStage.json
Now, I can get the exactly same file listed with a different command:
[17:44:19:~/Work/cloud-formation/output/templates$] cksum ManagementStage.json Managementstage.JsOn
cksum ManagementStage.json Managementstage.JsOn
3327010753 67569 ManagementStage.json
3327010753 67569 Managementstage.JsOn
Is it some sort of bash settings?
OK, it turns out MacOS disk partitions can be created case-sensitive or not, and default is apparently the second one
Disk utility shows the options when one is trying to create a new partition
enter image description here
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
I am working through this resource: https://cmdchallenge.com
On the following challenge: https://cmdchallenge.com/s/#/search_for_files_containing_string, the problem was:
Print all files in the current directory,
one per line (not the path, just the filename)
that contain the string "500".
When I ran:
ls -al
I got the following:
total 36
drwxr-xr-x. 2 501 dialout 4096 Feb 10 21:08 .
drwxr-xr-x. 39 501 dialout 4096 Apr 18 19:04 ..
-rw-r--r--. 1 501 dialout 204 Apr 29 17:44 README
lrwxrwxrwx. 1 501 dialout 23 Feb 10 20:59 access.log -> ../../common/access.log
lrwxrwxrwx. 1 501 dialout 25 Feb 10 21:08 access.log.1 -> ../../common/access.log.1
lrwxrwxrwx. 1 501 dialout 25 Feb 10 21:08 access.log.2 -> ../../common/access.log.2
I tried a few things, then looked at the user submitted solutions and one of them was:
ls *[^2]
I did some googling and the man page (and here), but I can't see what this is doing, or how it works.
Can anyone point me to a decent resource so I can read up on it, or tell me how it works?
Let me first quote PesaThes comment to what the command does:
The reference you are looking for is in the manual under: pattern matching. * matches any string, [^2] matches any character that is not 2. So the command lists all files that do not end in 2
Now why this is a solution to the problem is not so clear from your question alone. But if you look what the files contain you will notice that indeed, access.log.2 is the only one that does not contain the string 500 and also the only one whose name ends in 2.
For other sets of files the command ls *[^2] will most probably not output all the files without the string 500 in it, but in this case with those specific files it matches the right files. Another solution would have been for example
echo README; echo access.log; echo access.log.1
that's not an answer to your question, the right way of doing it is
$ grep -sl 500 * .*
-s skip errors (caused by directories); l only filenames; search in * all visible files and .* invisible files.
The /sys/class/gpio can only be accessed as root by default. So I like that a new group gpio can use the files and directories under /sys/class/gpio. To achieve that I added the following lines to /etc/rc.local (I'm on Debian):
sudo chown root:gpio /sys/class/gpio/unexport /sys/class/gpio/export
sudo chmod 220 /sys/class/gpio/unexport /sys/class/gpio/export
So this gives write permissions to all the gpio group members. So they can now export and unexport pins fine.
The problem is they can't read/write the specific pin files after export (e.x. /sys/class/gpio/gpio17) beacause those are owned by root:root again.
How can I change that they are created by default as root:gpio too? I mean I can do that manually each time I export a pin. But that's a bit uncomfy.
UPDATE
According to larsks' answer I created the missing rule file. Now it partially works:
-rwxrwx--- 1 root gpio 4096 Jun 19 16:48 export
lrwxrwxrwx 1 root gpio 0 Jun 19 16:51 gpio17 -> ../../devices/soc/3f200000.gpio/gpio/gpio17
lrwxrwxrwx 1 root gpio 0 Jun 19 16:45 gpiochip0 -> ../../devices/soc/3f200000.gpio/gpio/gpiochip0
-rwxrwx--- 1 root gpio 4096 Jun 19 16:45 unexport
But for the ./gpio17/ I still get root:root:
-rw-r--r-- 1 root root 4096 Jun 19 16:52 active_low
lrwxrwxrwx 1 root root 0 Jun 19 16:52 device -> ../../../3f200000.gpio
-rw-r--r-- 1 root root 4096 Jun 19 16:52 direction
-rw-r--r-- 1 root root 4096 Jun 19 16:52 edge
drwxr-xr-x 2 root root 0 Jun 19 16:52 power
lrwxrwxrwx 1 root root 0 Jun 19 16:52 subsystem -> ../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Jun 19 16:52 uevent
-rw-r--r-- 1 root root 4096 Jun 19 16:52 value
UPDATE 2
Okay I solved the problem. Because I installed Raspbian over the RaspbianInstaller I never went through the raspi-config tool. This seems to be a problem. Because I was also missing the /sys/device/virtual/gpio/ folder.
I followed this guide here: https://community.element14.com/products/raspberry-pi/f/forum/26425/piface-digital-2---setup-and-use#139528
And afterwards the permissions were correct (even for the pin-folders and their files value, direction, ...).
More common rule for 4.x kernels will be the following
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'find -L /sys/class/gpio/ -maxdepth 2 -exec chown root:gpio {} \; -exec chmod 770 {} \; || true'"
The rule in the initial answer will fail to chown the exported gpio if there's a symbolic link in the path
UPD please beg in mind that when you export some GPIO via sysfs, you should wait for udev rule to fire and complete before you get desired access rights. The thing that worked for me was sleep about 100ms before trying to access GPIO files.
You can do this using udev rules, which can define actions to execute when the kernel instantiates new devices. Current versions of the Raspbian distribution for Raspberry Pi devices contain the following in /etc/udev/rules.d/99-com.rules:
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio'"
This ensures that entries under /sys/class/gpio are always available to members of the gpio group:
# ls -lL /sys/class/gpio/
total 0
-rwxrwx--- 1 root gpio 4096 May 6 23:36 export
drwxrwx--- 2 root gpio 0 Jan 1 1970 gpiochip0
-rwxrwx--- 1 root gpio 4096 May 6 23:37 unexport
# echo 11 > /sys/class/gpio/export
# ls -lL /sys/class/gpio/
total 0
-rwxrwx--- 1 root gpio 4096 May 6 23:37 export
drwxrwx--- 2 root gpio 0 May 6 23:37 gpio11
drwxrwx--- 2 root gpio 0 Jan 1 1970 gpiochip0
-rwxrwx--- 1 root gpio 4096 May 6 23:37 unexport
Update
Permissions are correct for individual pins as well:
# ls -Ll /sys/class/gpio/gpio11/
total 0
-rwxrwx--- 1 root gpio 4096 May 6 23:37 active_low
drwxr-xr-x 3 root root 0 May 6 23:36 device
-rwxrwx--- 1 root gpio 4096 May 6 23:37 direction
-rwxrwx--- 1 root gpio 4096 May 6 23:37 edge
drwxrwx--- 2 root gpio 0 May 6 23:37 subsystem
-rwxrwx--- 1 root gpio 4096 May 6 23:37 uevent
-rwxrwx--- 1 root gpio 4096 May 6 23:37 value
Expanding on the answer by #roman-savrulin, here's a simpler version.
There's no need to run the rule on REMOVE events, only ADD events. There's also no need to run 'find' as the udev environment will supply the exact path of the sysfs directory containing the new GPIO pin's files. You can also use 'chgrp' to change only the owning group, and symbolic modes in 'chmod' to only add the group-write permission bit.
You'll still have to wait for the completion of the rule processing before trying to open the pin's files, but the process should complete more quickly with a simpler rule which only touches the minimum number of files necessary.
SUBSYSTEM=="gpio*", ACTION=="add", PROGRAM="/bin/sh -c 'chgrp -R gpio /sys/${DEVPATH} && chmod -R g+w /sys/${DEVPATH}'"
Check the groups you belong to:
userk#dopamine $: groups
userk sudo dialout
If you belong to dialout the following, if not, comment.
userk#dopamine $: ls -l /dev/gpiomem
crw------- root root /dev/gpiomem
This file mirrors the memory associated with the GPIO device. The output of the command means that the owner of the file is the root user and the group that "owns" it is the root group. The 10 characters represent the file type and the permissions associated with it. The current configuration allows the owner of the file to read and write to the file.
You want to be able to read and write that file if you want to control the gpios.
One option would be to modify the group owner and make it match with the one you belong to (dialout in my case) and set the permissions in order to allow all users of that group to read and write the file.
Long story short:
userk#dopamine $: sudo chown root:dialout /dev/gpiomem
userk#dopamine $: sudo chmod 660 /dev/gpiomem
Wait! This setting won't be persistent and will vanish after reboot.
See this post for further info about the topic
For Ubuntu run.
sudo apt install rpi.gpio-common
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Anywhere I ls -a folder contains files called "." and "..".
Anybody knows what is this stuff? Is this some system files? Is this some kind of a virus or something? I have hard time googling because of such file names.
Here is an example:
drwx------+ 12 mih staff 408 4 янв 16:49 .
drwxr-xr-x+ 91 mih staff 3094 20 мар 15:28 ..
-rw-r--r--# 1 mih staff 6148 4 янв 16:49 .DS_Store
-rw-r--r-- 1 mih staff 0 10 ноя 2011 .localized
-rw-r--r--# 1 mih staff 181 27 ноя 2011 Desktop.ini
-rw-r--r--# 1 mih staff 8198298 29 июл 2013 Dizzee Rascal - Bassline Junkie.mp3
Yes, those are system files.
A subdirectiry contains two directory entries that were used to navigate between folders in the early days of DOS.
The . entry is a directory reference to the same directory.
The .. entry is a directory reference to the parent directory.
Those are like regular subdirectories, but instead they point to directories that already exist.
Nowadays those wouldn't actually be needed, the system could interpret . and .. anyway, but in the early days they were needed for the system to find the way back to the parent directory.
"." is a representation of the current directory in Unix based systems. ".." Is for upper directory.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm just getting started with GPG. I've created a key pair and now have several .gpg files:
drwx------ 2 jason jason 4096 Feb 11 21:10 ./
drwx------ 90 jason jason 45056 Feb 11 20:49 ../
-rw------- 1 jason jason 9398 Feb 11 20:49 gpg.conf
-rw-rw-r-- 1 jason jason 2316 Feb 11 21:10 mypk
-rw------- 1 jason jason 1633 Feb 11 20:52 pubring.gpg
-rw------- 1 jason jason 1633 Feb 11 20:52 pubring.gpg~
-rw------- 1 jason jason 600 Feb 11 20:52 random_seed
-rw------- 1 jason jason 1794 Feb 11 20:52 secring.gpg
-rw------- 1 jason jason 1280 Feb 11 20:52 trustdb.gpg
Am I correct to understand that secring.gpg is my private key? This file is protected by my passphrase, right? Is it ok to just keep this file on my machine? Should I move it somewhere more secure (say a thumb drive)?
Am I correct to understand that secring.gpg is my private key?
From man gpg:
~/.gnupg/secring.gpg
The secret keyring. You should backup this file.
This file is protected by my passphrase, right?
If you set one, yes. Actually not the file itself is protected, but each contained key can be (you can have multiple private keys in your secret keyring).
Is it ok to just keep this file on my machine? Should I move it somewhere more secure (say a thumb drive)?
This depends on your needs and trust in your machine.
Do you have special security needs, share your machine or expect it to be hacked/stolen/...? Better put it on an external device and then reference it using --secret-keyring /path/to/secring.gpg whenever using gpg or put it into your gpg.conf: secret-keyring /path/to/secring.gpg.
Do you trust the integrity of your computer, possibly even encrypted your files on it? Will you have to use your secret key a lot? Better keep the file on your hard drive as this saves hassles with using gpg.
For putting your key on a separate device, think of using an OpenPGP card. Using one, your secret key will never leave that card (for signing and decrypting) but for backup purpose. Definitely increases nerd factor, too. ;)