Re: devfs(5) Permissions
On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote: I presume you'd push the rules in using sysclt or did you have something more filesystem like in mind? Nope, just a sysctl. I guess then you just need a sysctl which lets you read the rules for a given devfs mount point and another which lets you set the rules for a given defvs mount point. I don't know if we also need a global ruleset which is applied if the mount point speficic rules fail to match. The rules should be able to chmod and chown the nodes. Should it also be able to prevent the creation matching nodes also? You mentioned matching on the names drivers and nodes. Are there any other sorts of matching we are likely to need? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
In message [EMAIL PROTECTED], David Malone writes: On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote: I presume you'd push the rules in using sysclt or did you have something more filesystem like in mind? Nope, just a sysctl. I guess then you just need a sysctl which lets you read the rules for a given devfs mount point and another which lets you set the rules for a given defvs mount point. I don't know if we also need a global ruleset which is applied if the mount point speficic rules fail to match. True, forgot that. In that case lets make them a mount option using mux@ new nmount(2) systemcall. The rules should be able to chmod and chown the nodes. Should it also be able to prevent the creation matching nodes also? Yes. You mentioned matching on the names drivers and nodes. Are there any other sorts of matching we are likely to need? Ideally I would want to match on names, driver names and types, ie: name==ttyd0, driver==sio and type==tty, but I think the important thing here is to make it exensible in the future. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
In message [EMAIL PROTECTED], Crist J. Clark writes : I've checked the manpages, the files in /etc, and Googled, and I can't find the answer. I am begining to worry there isn't one. How does one change the permissions on dynamically created devices? That is, when the node comes into existence, it has the permissions I want, and not necessarily the defaults. The overall plan is that it will be possible to push a ruleset into the kernel which changes the defaults. ETA: this summer (If I have to do it, if somebody wants to help code it it can probably be done faster). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: devfs(5) Permissions
On 03-Mar-2002 (16:31:36/GMT) Crist J. Clark wrote: How does one change the permissions on dynamically created devices? That is, when the node comes into existence, it has the permissions I want, and not necessarily the defaults. You can (must?) use /etc/rc.devfs [...] # Setup DEVFS, ie permissions, links etc. [...] Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
On Sun, Mar 03, 2002 at 05:42:10PM +0100, Riccardo Torrini wrote:
On 03-Mar-2002 (16:31:36/GMT) Crist J. Clark wrote:
How does one change the permissions on dynamically created
devices? That is, when the node comes into existence, it has
the permissions I want, and not necessarily the defaults.
You can (must?) use /etc/rc.devfs
[...]
# Setup DEVFS, ie permissions, links etc.
[...]
I think some people missed the point of the earlier question. My
problem is with devices that are created dynamically as they get
used.
I can put,
chmod 640 /dev/bpf{0,1,2,3}
In rc.devfs, and I will have joy for the first four bpf(4)
devices. That command creates them and gives them the permissions I
want. However, once someone tries to use /dev/bpf4, a new device is
dynamically created with the default permissions, not the permissions
I want.
But creating 'n' devices at boot will do for now (especially since we
used to be restricted to 'n' bpf(4) devices in the kernel
configuration, so it almost resembles historic behavior).
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
On 03-Mar-2002 (17:02:35/GMT) Crist J. Clark wrote: I think some people missed the point of the earlier question. I'm really sorry :( Next time I'll double read the messages. Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Crist J. Clark writes : I've checked the manpages, the files in /etc, and Googled, and I can't find the answer. I am begining to worry there isn't one. How does one change the permissions on dynamically created devices? That is, when the node comes into existence, it has the permissions I want, and not necessarily the defaults. The overall plan is that it will be possible to push a ruleset into the kernel which changes the defaults. ETA: this summer (If I have to do it, if somebody wants to help code it it can probably be done faster). I have a very similar problem trying to sync my Handspring Visor as a regular user 'cos the devices only come into existance when you press the sync button. Do you have any designs for this ruleset stuff? From what you said at BSDconEurope it will have to be fairly complicated to achieve the your aim of being better than a static permission for a given device. Otherwise, one option would just be to have devfs check for a file in the /dev directory it is mounted over and then use that files permissions as a default. That would at least get us back the features of the old /dev which we're missing now. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
In message [EMAIL PROTECTED], David Malone writes: On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Crist J. Clark writes : I've checked the manpages, the files in /etc, and Googled, and I can't find the answer. I am begining to worry there isn't one. How does one change the permissions on dynamically created devices? That is, when the node comes into existence, it has the permissions I want, and not necessarily the defaults. The overall plan is that it will be possible to push a ruleset into the kernel which changes the defaults. ETA: this summer (If I have to do it, if somebody wants to help code it it can probably be done faster). I have a very similar problem trying to sync my Handspring Visor as a regular user 'cos the devices only come into existance when you press the sync button. Do you have any designs for this ruleset stuff? From what you said at BSDconEurope it will have to be fairly complicated to achieve the your aim of being better than a static permission for a given device. Not really, the basic idea is just a linked list of rules: name==/dev/uscanner* - chmod 0644 driver==bpf - chown user It's not too much work, I just havn't had the time for it yet. (Junior Kernel Hackers can apply here :-) Otherwise, one option would just be to have devfs check for a file in the /dev directory it is mounted over and then use that files permissions as a default. That would at least get us back the features of the old /dev which we're missing now. This is much harder than you think... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
Do you have any designs for this ruleset stuff? From what you said at BSDconEurope it will have to be fairly complicated to achieve the your aim of being better than a static permission for a given device. Not really, the basic idea is just a linked list of rules: name==/dev/uscanner* - chmod 0644 driver==bpf - chown user It's not too much work, I just havn't had the time for it yet. (Junior Kernel Hackers can apply here :-) OK - I thought you had something much more complex in mind after your example: plugging the nuclear reactor into the serial port where you had a a modem plugged in yesterday. I presume you'd push the rules in using sysclt or did you have something more filesystem like in mind? Otherwise, one option would just be to have devfs check for a file in the /dev directory it is mounted over and then use that files permissions as a default. That would at least get us back the features of the old /dev which we're missing now. This is much harder than you think... I didn't for a moment think it might be easy ;-) David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
In message [EMAIL PROTECTED], David Malone writes: Not really, the basic idea is just a linked list of rules: name==/dev/uscanner* - chmod 0644 driver==bpf - chown user It's not too much work, I just havn't had the time for it yet. (Junior Kernel Hackers can apply here :-) OK - I thought you had something much more complex in mind after your example: plugging the nuclear reactor into the serial port where you had a a modem plugged in yesterday. No, that was to show why persistence is a bad idea. I presume you'd push the rules in using sysclt or did you have something more filesystem like in mind? Nope, just a sysctl. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
On Sun, Mar 03, 2002 at 09:26:11PM +0100, Poul-Henning Kamp wrote: OK - I thought you had something much more complex in mind after your example: plugging the nuclear reactor into the serial port where you had a a modem plugged in yesterday. No, that was to show why persistence is a bad idea. Fortune(6), anyone?:-) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], David Malone writes:
On Sun, Mar 03, 2002 at 05:36:04PM +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Crist J. Clark writes
:
I've checked the manpages, the files in /etc, and Googled, and I can't
find the answer. I am begining to worry there isn't one. How does one
change the permissions on dynamically created devices? That is, when
the node comes into existence, it has the permissions I want, and not
necessarily the defaults.
The overall plan is that it will be possible to push a ruleset into
the kernel which changes the defaults. ETA: this summer (If I have to
do it, if somebody wants to help code it it can probably be done faster).
I have a very similar problem trying to sync my Handspring Visor
as a regular user 'cos the devices only come into existance when
you press the sync button.
Do you have any designs for this ruleset stuff? From what you said
at BSDconEurope it will have to be fairly complicated to achieve
the your aim of being better than a static permission for a given
device.
Not really, the basic idea is just a linked list of rules:
name==/dev/uscanner* - chmod 0644
driver==bpf - chown user
In the mean while they could temporarily hack their kernels to add the following
code to tty_pty.c.
(not tested)
static int pty_default_owner_uid;
static int
pty_default_owner(SYSCTL_HANDLER_ARGS)
{
int error;
int val;
val = pty_default_owner_uid;
error = sysctl_handle_int(oidp, val, sizeof(int), req);
if (error != 0 || req-newptr == NULL)
return (error);
if (your_favoutite_sanity_check(val)) {
pty_default_owner_uid = val;
}
return (0);
}
SYSCTL_PROC(_kern, OID_AUTO, pty_default_owner, CTLTYPE_INT | CTLFLAG_RW,
0, sizeof(int), pty_set_owner_uid, I, owner for newly created ptys);
and then use pty_default_owner_uid in the make_dev() call.
It's not too much work, I just havn't had the time for it yet.
(Junior Kernel Hackers can apply here :-)
Otherwise, one option would just be to have devfs check for a file
in the /dev directory it is mounted over and then use that files
permissions as a default. That would at least get us back the
features of the old /dev which we're missing now.
This is much harder than you think...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +--x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: devfs(5) Permissions
I've often thought that owner, group, and mode should be defaulted in the registration process for the device. This would let defaults be set in the source code, so in the worst case, you can rebuild the kernel to get them. This would also allow low granularity persistance to be handled in teh same way that kernel visual configuration handles it, or by minimally permitting modification of the data section of the kernel binary. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
