Change permissions on /dev file? [SOLVED ROOT ONLY XSANE execution problem]

Richard England rengland at europa.com
Fri Apr 21 05:47:27 UTC 2006


john bray wrote:
> On Sun, 2006-01-15 at 17:05 +0100, Toralf Lund wrote:
>   
>> Toralf Lund wrote:
>>
>>     
>>>>>>> How can I update permissions on a device file on an FC4 setup? I 
>>>>>>> mean, I know I can use chmod, of course, but the problem is that 
>>>>>>> for /dev special files, the changes are lost on reboot. [ ... ] 
>>>>>>>               
>>>>>>
>>>>>>
>>>>>> grep -n "sg" /etc/udev/permissions.d/50-udev.permissions
>>>>>>  
>>>>>>
>>>>>> The permissions are set there.
>>>>>>  
>>>>>>
>>>>>>             
>>>>> Right. I haven't quite got used to this new(ish) udev stuff... Seems 
>>>>> to me now it must be the place for the setting I want, but the 
>>>>> location you mention can't be correct for my system, as /etc/udev 
>>>>> has no permissions.d.
>>>>>
>>>>>           
>>>> Look to /etc/udev/rules.d
>>>> HTH
>>>>         
>>> I think I should be able to define an appropriate rule for my unit, 
>>> but I'm surprised to find that the udev doc does not mention a key 
>>> containing the device type or vendor/product id (as reported e.g. in 
>>> /proc/scsi/scsi.) Is there really now way to do direct match on those?
>>>       
>> Actually, it may look like SYSFS{type} will give me what I want (for 
>> device type.) I now have added
>>
>> KERNEL=="sg0", BUS=="scsi", SYSFS{type}=="6", SYMLINK="scanner", MODE="0666"
>>
>> which quite definitely has an effect, but not the one I want. In fact 
>> after I did this, the device is still owned by root and accessible by 
>> nobody else (i.e. has mode 0600.) Then if a user logs in via a local 
>> GNOME session, owner is changed to that user, and the mode stays the 
>> same. This is the same kind of behaviour as for CD-ROM, but is not right 
>> in this case, as I want to share the scanner across the net (via saned 
>> or just startup of the scanner software via ssh.) In fact, I'm not happy 
>> with the general trend of assuming the desktop user "owns" everything, 
>> as to me, flexibility in sharing resources is a very large part of what 
>> Linux is or should be about.
>>
>> Anyhow, how do I get udev to actually use the mode I've told it to use???
>>
>> - Toralf
>>
>>
>>     
>
> hey toralf -
>
> i had that same frustration.  i was sure that udev wasn't properly
> setting the permissions.  but...
>
> i suspect that udev is doing the proper permissions.  what you are
> seeing is the result of the pam security stuff
> in /etc/security/console.perms.d
>
> when a user logs in, the devices controlled by that system, have their
> owners and permissions changed as specified.
>
> i just finished putting up a file in that directory called local.perms
> because of scanner problems here.  the scanner part is:
>
> <scanner>=/dev/scanner* /dev/usb/scanner* /dev/sg*
>
> # permission definitions
>
> <console>  0666 <scanner>    0666 root
>
> i'm not yet sure that the /dev/sg* part is necessary.  note that 666 may
> not be what you want.  but, i sometimes su to other users for testing
> and its more convenient for me.
>
> you can use udevstart to rescan for devices and it appears to also force
> the console/pam stuff to re-do things as well.
>
> it appears that the perms files need to be named the reverse of the udev
> rules files.  as i currently understand it, with the perms files, the
> last one read is the winner.  but, with udev, it seems to be the case
> that the first one found is the winner.  so, my local udev rules are
> named 10-local.rules  but, my local console perms file is named
> local.perms, so it gets parsed after the 50-* file does.
>
> still in the process, so YMMV.
>
> john
>
>   

This may be ancient history but I don't believe I ever saw a follow-up 
to this. 

I followed your instructions, John, and after a logout/login the 
permissions on my scanner were opened to all my users.

Thanks for sharing this information.

-- 
--R
------------------------------------------------------------------------
/Linux, and Open Software, an alternative./
Registered Unix <http://counter.li.org> user #409453




More information about the fedora-list mailing list