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
