udev.rules & ttyS0 device

lordwolf · 05-23-2008, 04:15 AM

Hi all,

I'm trying to give serial port access to my user account by adding it to the uucp group. I noticed the udev rules files has an entry that creates the symlink /dev/ttyS0 to /dev/tts/0 - from what i understand, each should be owned by root:uucp.

but after failing to run minicom, i noticed the the /dev/ttyS0 symlink is owned by root:root. my question is, should i manually change this? or have i missed something?

thanks.

tobyl · 05-23-2008, 12:31 PM

Hi lordwolf

I don't think the group uucp has got anything to do with it.

symlinks are usually lrwxrwxrwx, so the owner and group of a symlink are largely irrelevant, its the file the symlink points to that matters. Of course you could test if permissions were your only problem by testing as root.

Have you got a driver loaded for your serial device?

look for 8250 in the output of lsmod.
if its not there, try
modprobe 8250

then when your serial device is connected, try minicom again.
If there is a permissions problem, you can test by temporarily modifying the perms on the device with say
chmod 666 /dev/thedevice

if that makes a difference, then you could look at modifying the perms in your udev rules

good luck,

tobyl

lordwolf · 05-24-2008, 03:05 AM

hi tobyl,

maybe i was not specific. my serial connection is working fine using root account. i was trying to get it to work on my user account. the owner of /dev/ttyS0 link is root:root (the udev rules should have set it to root:uucp, just like the actual device file /dev/tts/0) - so, even when i added my user account to uucp group, minicom simply fails.

so, my point is, do i have to manually "chown root:uucp /dev/ttyS0"?

thanks.

tobyl · 05-24-2008, 12:11 PM

hi lordwolf,

I didn't realize you had it working for root already.
I see what you mean about the uucp group.
I can't understand why putting yourself in the uucp group doesn't work, but I tested it myself and found the same thing.

Well, I remember what I did to get it working for users, though it allows all users access which may or may not concern you.

if you create a file called 90-local.rules in
/etc/udev/rules.d

then add the line

KERNEL=="ttyS[0-9]*", NAME="tts/%n", SYMLINK+="%k", GROUP="uucp", MODE="0666"

it will supercede the 40-slackware.rules to allow access to users. This is preferable to modifying 40-slackware.rules directly, as your local.rules file will survive udev updates, and also you know where to find changes you made to your system easily.

tobyl

edit: by the way, you can update the udev configuration without rebooting, by running

udevtrigger

as root, after you have saved your changes to udev rules

lordwolf · 05-25-2008, 09:12 AM

hi tobyl,

thanks again for the reply. that's the thing about udev - i never really understand the rules file. the way i read the file, i thought the symlinks should already be as i expected (owned by root:uucp). if that is the case, i just thought i want to know why has it changed? what made the changes? or did i mis-interpret it?

i'll try adding a local rules file as a last resort. i just wouldn't want to add anything to what is already there unless i really need to

tobyl · 05-25-2008, 04:52 PM

Hi lordwolf,

You do seem to have found an anomaly.

If you run

ls -l /dev/tts*

do you get

crw-rw---- 1 root root 4, 64 2008-05-25 22:15 0
crw-rw---- 1 root uucp 4, 65 2008-05-25 22:15 1
crw-rw---- 1 root uucp 4, 66 2008-05-25 22:15 2
crw-rw---- 1 root uucp 4, 67 2008-05-25 22:15 3

that's what I got at first, which explains why adding your user to uucp doesn't work. (first line refers to tts/0)
so then I did (as root)

chown root:uucp /dev/tts/0

then I got

crw-rw---- 1 root uucp 4, 64 2008-05-25 22:17 0
crw-rw---- 1 root uucp 4, 65 2008-05-25 22:17 1
crw-rw---- 1 root uucp 4, 66 2008-05-25 22:17 2
crw-rw---- 1 root uucp 4, 67 2008-05-25 22:17 3

most surprising is that this change survives rebooting!

this implies to me that there is a bug in the implementation of udev, that doesn't [always] change the group assignation. But that still doesn't explain to me why tts1-3 get the correct group.
Of course there are variables that I may not have considered.

I suggest that you chown /dev/tts/0 as I did, and see what happens.

One other point. You keep mentioning the symlinks. I really don't think this is relevant.

if you do

ls -l /dev/ |grep ^l

you will see that there is not a single symlink in /dev that isn't

lrwxrwxrwx 1 root root

tobyl

lordwolf · 05-26-2008, 04:52 AM

hi tobyl,

this is why i keep mentioning symlinks..

Code:

$ ls /dev/ttyS* -l
lrwxrwxrwx 1 root root 5 2008-05-26 16:59 /dev/ttyS0 -> tts/0
lrwxrwxrwx 1 root root 5 2008-05-26 16:59 /dev/ttyS1 -> tts/1
lrwxrwxrwx 1 root root 5 2008-05-26 16:59 /dev/ttyS2 -> tts/2
lrwxrwxrwx 1 root root 5 2008-05-26 16:59 /dev/ttyS3 -> tts/3

minicom configuration is set to /dev/ttyS0. that's kind of the standard device file for serial ports. my /dev/tts 'status' is what as it should be (i didn't make any changes to it):

Code:

$ ls /dev/tts/* -l
crw-rw---- 1 root uucp 4, 64 2008-05-26 16:59 /dev/tts/0
crw-rw---- 1 root uucp 4, 65 2008-05-26 16:59 /dev/tts/1
crw-rw---- 1 root uucp 4, 66 2008-05-26 16:59 /dev/tts/2
crw-rw---- 1 root uucp 4, 67 2008-05-26 16:59 /dev/tts/3

i still can't find how this can happen. still gazing at the rules file

tobyl · 05-26-2008, 06:10 AM

Hi lordwolf,

What you show in your last post is perfectly correct and as it should be.

I think you may have a misunderstanding about symlinks.
They are transparent shortcuts and do not impose permission restrictions.

Quote:

lrwxrwxrwx 1 root root

see how the whole world has read, write and execute permissions?

the owner and group of the symlink is thus rendered irrelevant, and simply reflects which user created it, and that owner's default group.

After putting myself in the uucp group (and logging out and in again) with the corrected permissions on /dev/tts/0 (evidently not an issue in you case) I could access "/dev/ttyS0" without a problem.

One thing i found in my travels, there is sometimes a minicom.users file in /etc. You may need to check that is ok.

tobyl

lordwolf · 05-26-2008, 09:01 PM

hi tobyl,

You're right... I was so wrapped-up with the owner thingy to notice about the permission - thanks!

hmm.. still, that doesn't solve my problem. my minicom.users file has an "ALL" entry - which I assume is okay for all users. well, i guess as far as the topic is concerned, this thread is done

i'll check for other minicom settings to see what else i can tinker with

EDIT: minicom is now working for my user account! i think it was my mistake of not doing more testing. i added my user account to the uucp group using kuser - and tried minicom from an opened console (which may not have updated the group change?). anyways, all is working now. just thought i should mention it to give this thread a real closure